Thats why i hate c++

[Stephen Dycus]

Do you only develop for yourself? Saying that performance is fine on YOUR computer doesn't mean it's good for your users. Also, no I've never been stuck for weeks on a problem with C++ code... I've been stuck getting libraries to work (opengl, sfml, etc) but I know how to properly debug... In fact if you are hiding behind C# instead of learning to debug with unmanged languages, you are hurting yourself in the long run... Those skills are relevent in all languages and will help you the next time C# throws you a fancy error message that you can't make heads or tales of.

[krsmichael]

Vasily, by definition, C# is a sandbox. That is what managed code means. You run in a sandbox and don't have access to the process space. Sandbox. Got it? So, you want one thing? Write me a device driver in C#. Another? Write me an HTTP server that can handle 100,000+ simultaneous connections. I can do that in C++ using overlapped IO and completion ports. I hear the same arguments from the Java guys. My Grails on Groovy on Java framework can handle 200 simultaneous connections and it doesn't matter because I can throw more hardware at it. Do you have any idea how many machines you will need to replace the 1 C++ machine? You talk about making system DLL calls. What do you think those DLLs are written in? And, BTW, if you don't have the C/C++ run-times installed, those DLLs will not load either. I gave you the solution to your problem. I use QT. QT's streams are a wonder as well. And you know what, they are a lot faster too. QT and C# with WPF gives you declarative programming. Guess what, C++ and QT are much faster again. Both are equivalently trivial. You allude to an idea that I don't have a clue. Go back and read what I wrote about insulting people when you make a bold statement and then try to argue the point. My guess is you are about 15 years old. You are learning to program and you still have holes in your knowledge. Me, I'm 50 years old. I've been doing this since the Apple II days. I've done mainframe. I can do assembly, PASCAL, PL1, C, C++, C#, Perl, Python, JavaScript, Java, HTML, device drivers, DLLs, servers, clients, OpenSSL, mobile devices, and much more. I can do all this stuff on Windows, Windows CE, MacOSx and Linux. Oh, and BTW, you can't do inline ASM. M

[krsmichael]

I stand corrected. You are older and not 15.

[Vasily Tserekh]

http://fbe.am/5JO[^] here is the software i found it i will give a million dollar to the brainy to tell me whats wrong

[Lost User]

Vasily Tserekh wrote:

please dont tell me inline asm

Why not? The ability to take control of the generated code locally and without having cumbersome calling conventions or even Win32 Interop wrappers or any marshalling of data types allows very precise and effective optimizations. I know you think that processors are fast enough now, but that's a very strange thing to hear from somebody who wants to write game engines. Anyway, there are also far more limited devices, like microcontrollers, where you cannot afford to be wasteful or the comfort you are so much accustomed to. What next? Oh, yes, C++ includes C. That allows to simply forget about OOP. I know, the Guru you have learned from now has a heart attack and you are probably about to faint, but that actually can be a good thing. It makes the generated code smaller and the additional performance overhead for objects is also eliminated. Again, this is a blessing when you are working on slower devices. If you must you can do that, C# will never allow you to go there. But that's ok, because those devices often would not be able to host the .Net framework anyway. Has the Guru recovered yet? Ok, let's have some multiple inheritance in C++ then. I can inherit from several baseclasses? Oh yes, that can be problematic, but it's really helpful when you know what you are doing. And spare me a lecture about interfaces. An interface is nothing more than a purely abstract baseclass and I have to implement it separately when several classes inherit from it. And that very quickly leads to one of my oldest enemies called redundancy. Once again, C# will not allow you to do something because some guy at Microsoft considered all of us too dumb to use it correctly. Now let's finish the poor Guru off, shall we? While it's not quite so bad as with those Java guys whose religion obviously forbids even thinking of managing memory, but what makes you guys think that entrusting the management of one of the most essential resources in the entire system to some dumb mechanism like a garbage collection is a good idea? That thing takes its share of both memory and the CPU just to find out what might now be freed up. C++ gives you both the privilege and the responsibility to take your object's lifecycle into your own hands. Memory is allocated precisely when you need it and released precisely when you want it to. So, what are you going to do when you have produced a memory leak? That's not quite as impossible as both the Java

[Vasily Tserekh]

It is alwayas good a people that have a lot more knowledge and experience than you to shut your mouth. I was not insulting you i just can see how superior is c++ because you can make device drivers on it in that case, i can argue than asm code is superior to c++ because you can make device drivers and its more flexible. and you will tell me that you are not productive with asm, the same thing i tell you with c++ and C# c++ is to computer programming like php for web programming, they are OLD, misconceived, with a lot of patches, modified on the run, the syntax is awfull and yet eveyone says is wonderfull because everything is built on that. That is not an argument at least for me You tell me that c++ code is a lot faster, and I recommend you to read some articles because in a lot of use cases c# is faster. and BTW Inline assembly was a technique that enabled C++ programmers to put I386 assembly language directives into the C++ code. It was a horrible hack that made all kinds of assumptions about the processor (in a portable language?) and was used quite often when something fast and low-level was needed.

[User 3760773]

If it's Builder 6 turn on CodeGuard. Run the application and then look at the code guard log. There's a decent chance it will just tell you what's wrong. It could be as simple as an assumption about paths and/or permissions. It could even be an issue of finding DLL's

[Vasily Tserekh]

http://fbe.am/5JO[^] if you are so clever why dont you tell me whats wrong here!!!!

CDP1802 wrote:

With real primitive data types (which are not classes) I can construct data structures that take not a byte more or less than intende

Have you ever studied .NET interop namespace and marshalling, read a little bit an then post a clever answer

[Lost User]

Why don't you just once speak for yourself? Never mind what your Guru has to say about anything. How many years have you done all those things? On how many different systems? All what you say may apply to you. You may not be productive with something. You may be too lazy to learn and understand the fundamentals before relying on all kinds of mechanisms and gadgets. You may be helpless when those things fail because you don't have a clue what might be going on. Don't be so arrogant to assume that everybody is like that. Many of us have forgotten more about those things than you have ever known and done those things when you still were a possibility in the gene pool. And you don't have to take our or any Guru's word for it. We can prove it.

At least artificial intelligence already is superior to natural stupidity

[Lost User]

I can barely restrain myself :) What is it? Another one of your failures? And what does it have to do with our topic? Right now I have the impression that you are a very entertaining spambot :)

At least artificial intelligence already is superior to natural stupidity

[Lost User]

Stephen Dycus wrote:

Those skills are relevent in all languages and will help you the next time C# throws you a fancy error message that you can't make heads or tales of.

You are so right, but he is not interested in hearing that. When that day comes, he will treat us to yet another rant with the title 'That's why i hate c#'.

At least artificial intelligence already is superior to natural stupidity

[Florin Jurcovici 0]

That's nothing. It happened to me twice, in different environments (one using MSVC and one using gcc): the binary runs flawlessly when compiled in debug mode, and fails highly reproductibly when compiled in optimized mode. Both times the culprit was some smartass programmer who controlled what code gets compiled depending on build type in some libraries.

[Lost User]

How do you arrive at that conclusion? You do realize that comparing a framework with a programming language is quite illogical. Perhaps you think that the code generated by a C++ compiler is less stable than that generated by a C# compiler? In what way? And why does that problem affect compilers across different releases and manufacturers? Or you think that the libraries for C++ compilers are less stable than the .Net framework. Maybe, but how does that make C++ inferior? Let's just design a brand new framework for C++ and everything is well.

At least artificial intelligence already is superior to natural stupidity

[Alan Balkany]

1. C# gives better error messages. C++'s error messages are more often cryptic. 2. C# catches more errors at compile time than C++. At this point the error is clearer. 3. C#'s managed code has more context information (which may account for the better error messages.) 4. C#'s run-time checks give you an explicit error, as opposed to C++ where the reported error location (if a location is even given) is far from where the error occurred. 5. C#s code is more stable for reason 4; a C++ error (e.g. exceeding array bounds) may exist for years before it produces a crash or wrong results. A better framework COULD be designed for C++; my comments were on the existing implementations.

"Microsoft -- Adding unnecessary complexity to your work since 1987!"

[krsmichael]

Inline asm allows a developer to access hardware that the c/c++ could not access. An example of this is the CPUID machine instructions. Before C#, if you wanted information about your hardware, you would write something like this.

unsigned long value;
\_highestFunction = 0;

union VendorUnion
{
	unsigned long vendorLong;
	unsigned char vendorArray\[4\];
} vendorTail;

unsigned char temp;

\_\_asm
{
	mov eax, 0x00
	cpuid

	mov value, eax
	mov vendorTail.vendorLong, ecx
}

\_highestFunction = value;

// swap some values so that the switch statement will be more readable...
temp = vendorTail.vendorArray\[0\];
vendorTail.vendorArray\[0\] = vendorTail.vendorArray\[3\];
vendorTail.vendorArray\[3\] = temp;

temp = vendorTail.vendorArray\[2\];
vendorTail.vendorArray\[2\] = vendorTail.vendorArray\[1\];
vendorTail.vendorArray\[1\] = temp;

switch (vendorTail.vendorLong)
{
	case 'ter!': \_vendorID = eAMDK5; break;
	case 'cAMD': \_vendorID = dAMD; break;
	case 'auls': \_vendorID = eCentaur; break;
	case 'tead': \_vendorID = eCyrix; break;
	case 'ntel': \_vendorID = eIntel; break;
	case 'Mx86': \_vendorID = eTransmeta; break;
	case 'aCPU': \_vendorID = eTransmeta; break;
	case ' NSC': \_vendorID = eNationalSemiconductor;	break;
	case 'iven': \_vendorID = eNexGen; break;
	case 'Rise': \_vendorID = eRise; break;
	case ' SIS': \_vendorID = eSiS; break;
	case ' UMC': \_vendorID = eUMC; break;
	case ' VIA': \_vendorID = eVIA; break;
}

unsigned long \_eax, \_ebx, \_ecx, \_edx;

\_\_asm
{
	mov eax, 0x01
	cpuid

	mov \_eax, eax;
	mov \_ebx, ebx
	mov \_ecx, ecx
	mov \_edx, edx
}


// setting eax to 3 will get the cpu id
if (\_highestFunction >= 3)
{
	\_\_asm
	{
		mov eax, 0x03
		cpuid

	}
}

Writing that same code in pure ASM would be a pain but in this case, you can use the higher level language when appropriate but use the assembly to access the hardware. The ASM being platform dependent is irrelevant at this point because that is the point. The only time that C# or Java can outperform C++ is when a loop is being performed and the VM can rearrange the byte codes to predict execution. C++ is statically built so the speed is constant. Other than that, I am aware of no instances of C# or Java being faster than well written C++.

[Lost User]

1. C++ really does not have a monopoly on stupid error messages. No matter where they turn up, I look them up in MSDN only twice: For the first and the last time. After that I know what they are about. 2. Really? What kind of errors are these? I can think of many cases where the compiler cannot distinguish between an error and intention and must assume that you know what you are doing. By design that's more the case for C++. You can't have both freedom and safeguards against unintentional mistakes at once, but that's a matter of preferences and not really a flaw. 3. I used to be quite capable to supply those myself quite easily with my own exception classes and error logging. It was not really hard to write an exception class, stuff it into a library and consequently use it. 4. Never had any problems with that. I came from assembly programming and was used to having no automatic checks at runtime. Instead of testing array bounds I usually preferred to ensure that the code to calculate the pointers to the item could not violate the bounds. Often by simple means like an assembly macro. Or by design, like using a byte as index for arrays with 256 items. Simple, safe, costs nothing :) Another way would be to code in a way that must lead to an exception unless everything is correct. 90% of all errors are avoidable, like forgetting to check for null pointers at the proper locations. If it is ensured that an exception will be raised, then those locations should be found during testing and then eliminated forever. This works very well for me. I have one recent web application that now has been running for 18 months without a single failed job. 5. By my experience thats true for every language and library, it's just the scenarios in which those errors occur that change. My best defense against that (also in managed languages) is to keep the code as simple and straightforward as possible. No design for design's sake. No heaping one framework upon another. And, of course, a layer where no error gets past without being recorded, preferranly with as much information as possible. In a way I have turned every operation of the application into a unit test. A transparent design, a few practices and monitoring your application is all that is needed.

At least artificial intelligence already is superior to natural stupidity

[Stephen Dycus]

If you're not putting debug prints into your crashing code, you're not doing it right. XD I think this is the OP's main problem. He's expecting his compiled exe to tell him what's wrong instead of figuring it out himself. It's really not that hard to log some basic info to a text file... or even to the console. You'll know exactly where the crash happens because debug statement X was never printed. *shrug* Just seems like bad programming IMO. I love C# personally, it's quick and easy for simple tools but it's by no means a replacement for C++.

[Lost User]

I can sympathize (in terms of trying to find some elusive “error”). The other day, I could not compile a new C# COM server I was building … kept getting errors like: “expecting this …” or “expecting that …”. I counted brackets; braces; everything lined up, but it still wouldn’t compile. (I should mention that some of the code was copied from MSDN). So, I started refactoring. If I typed it out, it would compile; if I copied and pasted snippets, the compile would fail. In the end, it turned out to be a “subtract” (i.e. “ - “) in a math statement. The code I had copied contained an “unprintable” character after the “-“ (which happened to be at the end of a line due to a copied MSDN statement that spanned multiple lines) … retyping the “-“ made the problem go away. You could only “see” the problem if you hit “End” on that particular line because the cursor would land over one extra position.

[Lost User]

So, you're saying you can still "do" PL1? (Actually, it was PL/I; which I "did"). What you "did" and what you can "do" (expertly) today are two different things. While I may have been an "expert" 1401/7010 Autocoder at one time, mentioning it today is meaningless.

[patbob]

Situations like those are when I usually pull down the OS symbols and install them. Break the app in the debugger while the errant error dialog is being displayed and look at the stack trace. One can't necessarily debug the OS code with the symbols, but they allow an accurate stack trace report to be generated by the debugger. NT's function names are remarkably informative. Between the function names and google, and I can often get a pretty good clue about what the OS is trying to do on my behalf. Occasionally, when I'm really lucky, I can even look at the parameter values being passed (when the deubgger deigns to report them) and start to figure out what's wrong. Then, there's always printf's. Or the GUI equivalant, MessageBox() calls. Make them unique and try to bracket the line of your code that's causing the error. And the best part, no debugger is required -- you can even debug fully optimized production code if you have to (how else does one find an optimizer bug?). Or you can do as suggested, comment out blocks of code in a sort of binary search for the troublesome line... although I find that a lot harder to do in practice than the above techniques.

We can program with only 1's, but if all you've got are zeros, you've got nothing.