Thats why i hate c++

[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.

[KP Lee]

The point the other two posters were making is that there are two exe files created. One in the debug folder and one in the release folder. Both are application folders. The one in the debug folder should work just like the IDE launch.(I'm not sure breakpoints are reccognized outside the IDE. I seem to remember not without linking to the mapping file. Don't remember the file type, but if you map to it and blow up, the IDE is brought up for you and your local environment at the time of blowing up is available for viewing. I read how to do this in 2005, very useful at the time, got away from programming for a while so don't remember how that is done) So, you KNOW you are double-clicking the DEBUG folder's version of the code and it doesn't work? Do you know how to bring up the IDE from a double-click? Earlier, you said the drive letter you started from is causing the problem. From that, I assumed you started the app from a cmd file. Since you are double-clicking, are you navigating to the drive causing the problem in the app? If not, how do you know it is a drive permission problem?

[KP Lee]

I don't like C++ either, but it's because I rarely use it and I like the pampering you get with managed code. I do like the IDE and I definitely don't completely understand it. I have to agree with you, that I don't like it when something goes wrong and I don't understand what is happening to cause the problem. It's worse when I don't understand what it is that I need to understand. I have to admit to berating the perpetrator after I've traced the source of the problem. For some reason, I don't take it personally when I'm berating myself. (Why is that? How more personal can you get? :-D )

[KP Lee]

code_junkie wrote:

If you wanted to teach a monkey how to code...

Is that right after it writes out the entire works of Shakespeare on a typewriter? Uhh, do you know what a typewriter is?

[SlingBlade]

You're a good person! :-D

[KP Lee]

That “uncertainty” sure shows up in a lot of places. One time I didn't have an IDE, and I'm getting duplicates. Comb over the code, can't find the logic problem. Insert write statements. Problem disappears. I'd had this happen in the past and the problem reappeared when I took out the write statements. This time, the problem remained gone and has stayed gone since. It's frustrating I'll never know what caused the problem or exactly what I did that fixed it. When it reappeared that earlier time, I think it took a week to find the single line of code that was a problem, and about the 20'th time re-reading that line.

[krsmichael]

I would not be be able to code PL/I at the level I was doing it in the 80's. Although I still remember segments of PL/I, JCL and ISPF. I wrote channel drivers. I wrote an implementation of Kermit in PL/I. Yeah, I think I had it wired. Today, I'd have to get reacquainted with it again. I was definitely an expert and was made the IBM mainframe advisor for General Dynamics Western Division. As far as meaningless, I disagree. One of the strengths I bring to a job is the vast diversity of languages I've used. There is nothing new under the sun and I've reverted to ideas that I was exposed to, to implement "novel" things today. I am not familiar with Autocoder but I'm certain there were novel constructs that would be applicable to solving problems today. I started C++ with CFront on MPW. I've been with it to the present. However, it isn't a one tool fits all. I use other tools when they make sense. The aversion to the "I hate C++" post is due to the history of seeing this posted and then accepted as fact. I work for Qualcomm. I use C and C++ a lot. When I recruit at local technical colleges and the hardest thing they have had to develop with is Java, I find it hard to take the student's education seriously. I want to see students who know assembly. Not so that they can code in it, but to demonstrate they have some knowledge of what is going on underneath the covers. We want to know that the person has the ability to resolve issue not only at the software level, but at the hardware level as well. But to answer your question, I do a lot of things expertly. I've worked on many projects that has personally affected you or those around you.

[wcsystems]

As a C/C++ coder who started as a .NET coder, I hated C++ to start with. I can honestly say that over the last few years it has really grown on me. I am forced to agree that a well-done c++ application is a thing of beauty. I am still more productive using .Net though, as it generally requires less code to get stuff done.

[Member 8697068]

Your environment may be different when you run the debugger verses just launching the exe file. Check "PATH" when executing both. Also, as I use to do, kill the program with print statements. You can do a "binary search" with print statements. One at the beginning, one in the middle and one at the end of the program. See which one prints and move them around accordingly. THE OLE HACK ;P

[mandyedi]

Did you try compile your code with other IDE?

[StephenPhillips]

It's just as well you've had an error like this - hopefully if/when you fix it, you'll have a more structured method for debugging in the future. It is not a good idea to write code with the approach of build and run it hoping it works; you have no idea what could be going wrong under the surface. If I was faced with an empty error dialog, I think my approach would be as follows (Apologies in advance, I'm not familiar with C++ Builder 6)

- Track down 'when' the error occurs. We know it happens as you open the program, so try building some more useful output into the program. It sounds like you're unable to debug line-by-line, so I'd try bringing up an output dialog each time something works properly - print some useful text to say what was done, etc. - Find the offending operation/function that is causing the issue. With the information you've provided, I'd keep an eye out for any file loading stuff that may be involved; perhaps your file loader can only handle absolute paths and it's being fed relative ones. - Replace the suspect code with a simple test - instead of trying to load a file, perhaps output a "Loading file [path+filename]" message. If it doesn't come up with the blank dialog anymore, you know which line causes the issue. I'm far more used to debugging by pressing F10 until it breaks in Visual Studio, so this is effectively a more long-winded approach to doing the same thing. - Fix the offending code. Naturally, you still need to be able to load the file; I'm unfamiliar with your program's requirements, but if it's plain C++ loading a data file (binary or text, usually) then you should have no problems using an input stream[^]. I can promise you that this definitely works, and won't give you blank error messages.

If you find errors in your code, it shouldn't matter if you get nonsensical or unhelpful messages - that's often the flavour of the day when it comes to programming. You need to break it down into each step to find out what's wrong, which inherently helps you understand your own code (or other people's code) better. Happy hunting!

Sometimes a fist in the face says more than a thousand honeyed words.