Don't get screwed by C

[KenR]

The image (see below) says it all...

To get on this list, a bug has to be able to cause at least half a day of futile head scratching, and has to be aggravated by the poor design of the "C" language.  In the interests of equal time, and to see how the world has progressed in the 20-odd years since "C" escaped from its spawning ground, see my Top 10 Ways to be Screwed by the Java programming language, and for more general ways to wase a lot of time due to bad software, try my Adventures in Hell page.

A better language would allow fallible programmers to be more productive. Infallible programmers, of the type unix' and "C" designers anticipated, need read no further.  In fairness, I have to admit that the writers of compilers have improved on the situation in recent years, by detecting and warning about potentially bad code in many cases.

http://www.andromeda...le/ddyer/topten.html

from www.stumbleupon.com

[SkyIDE]

Once I put a \ in a commented section with //

The program didn't work the way it was suppose to and I couldn't figure out why I was getting funny results and I coudn't see the reason for it. I did spend a lot of time on it and believe it or not, because I had \ in my comment, that part was effecting the output result of the next non-commnted statement.

Here is a proof of concept code. You have to type this exactly as it is. Including the line spacing

[Select]

    int iVar = 0;
    // this a test C:\
    iVar = 3;
    ShowMessage(IntToStr(iVar));

Execute the program, you will get 0 in the message that pops up.


BUT if you type this:

[Select]

    int iVar = 0;

    // this a test C:\
    iVar = 3;
    ShowMessage(IntToStr(iVar));

you will get what you would expect, 3 in the message box. Pay attention to the line spacing between int iVar = 0; and the next line, the commented one.



Imagine the frustration I went through. I was literally frustrated. I spent HUGE amount of time debugging, going step by step, executing line by line to figure out why I was getting funny output.

I realised after I saw the warning produced by the Borland C++ compiler:

Warnning: Continuation character \ found in // comment

I was shocked. Who would expect something like this? A perfect code giving you completely incorrect results? Imagine the pain I went through to catch that! The error being somewhere you are not looking. How can you find an error if you are debugging  the wrong section!

The Borland C++ compiler did good over here, obviously the designers knew about this silly thing so they also made a warning about it....


UPDATE: I just tested the code with GNU C++. Guess what, GNU C++ didn't give ANY warning while Borland's bcc32.exe did produce a warning!!

[Select]

    int iVar = 0;
    // this a test C:\
    iVar = 3;


    cout << iVar << endl;

output is 0! but how can it be??? I just said it should be 3! Argh!! Even now I get frustrated lol. This can seriously stuff you up!


 

[mouser]

hehehe

it's the continutation character \ at the end of the comment line, saying that the comment is continuted on the next line, resulting in the "iVar = 3" line being considered part of the above comment.

i think your earlier explanation was probably off a bit.
you probably meant to say that if there was a blank line after the // comment line then it would work.

in other words THIS will produce the desired result of 3, because the blank line after the comment line ends the comment continuation.

Code: C [Select]

1. int iVar = 0;
2.     // this a test C:\
3.  
4.     iVar = 3;
5.     ShowMessage(IntToStr(iVar));

[mouser]

this is a good example of some evil stuff in c and c++ that is only still there because no one dares fix it for fear of breaking billions of lines of existing deployed code..

[mouser]

the #2 example in the above page is what i consider the canonical example of a language mistake designed to give coders power but which has had dramatic negative effects, the fact that an assignment can result in a value which can then be used in conditional expressions:

Code: C [Select]

1. if (a=b) dosomething();

as you know if you are c/c++ person, what the coder probably meant was to test for equality (the == symbol):

Code: C [Select]

1. if (a==b) dosomething();

i really wonder if this mistake might qualify for the single most common programming-language specific bug in the history of the world.

this is the kind of thing no langauge should permit.  languages need to be designed for clarity of expression and resistence to such mistakes that cant be detected as errors.

[SkyIDE]

regarding the "if" statements

I have "unintentionally" done something like this:

[Select]

if (something < some_thing else);
             ShowMessage ("Test");           

pay attention to the terminating char at the end of the "if" statement

Of course, the program didn't work as expected until you realise you have put ";" at the end of the "if" statement.

Basically, the code/statement between the closing brace ")" of the if statement and the ";" char gets executed but in this case, it is an empty statement ";" and nothing gets executed and a normal program flow continues to the next statement "ShowMessage("Test");

[mouser]

yes that's the other really classic c error.