Why I hate c

[Alan Anderson]

void User_Autonomous_Code(void)
{
  while (autonomous_mode)   /* DO NOT CHANGE! */
  {
    if (statusflag.NEW_SPI_DATA)      /* 26.2ms loop area */
    {
        Getdata(&rxdata);   /* DO NOT DELETE, or you will be stuck here forever! */
        /* Add your own autonomous code here. */
        // [state machine implementation]
        Putdata(&txdata);   /* DO NOT DELETE, or you will get no PWM outputs! */
    }
    Process_Data_From_Local_IO; 
  }
}

It took me four hours last night to figure out why Process_Data_From_Local_IO never gets called.

[roknjohn]

I totally agree. I'm a professional software engineer with 20 years experience. C is such an unforgiving language. It is difficult to read, easy to make simple errors in syntax, and most compilers won't warn you about things like:

 Process_Data_From_Local_IO;

Or, the one that gets me all the time:

  if (myvar=0) 
		   { 
			   dosomething(); 
		   }

[Dave Flowerday]

Originally Posted by roknjohn

if (myvar=0) 
{ 
  dosomething(); 
}

If you get yourself in the habit of specifying the constant first then the variable, you'll produce a compiler error if you only have 1 = sign. Our coding standard at work specifies this as a requirement to catch at least some of these types of errors. The above code would then become:

if(0 = myvar)
{
  dosomething();
}

which will give an error. Doesn't solve all the problems but it at least allows you to catch a few simple mistakes...

[deltacoder1020]

also the reason

Process_Data_From_Local_IO;

does not give an error is because it is a valid statement. it evaluates to the memory address of the Process_Data_From_Local_IO function. Now you might ask, "well, why doesn't if give a warning at least, because the line doesn't do anything"? Well, then you wouldn't be able to use the following code without a warning either:

x++;

because technically, that line just as much of "nothing". it evaluates to the value of x, and then increments it.

[Ryan M.]

Using a utility like Lint can help with those sorts of errors. Just run it and it will warn you of anything that you probably didn't mean to do.

[Astronouth7303]

Code is only as readable as you make it. Make names self-explainatory (or close to it). I tought myself VB, and my naming conventions are based on that.

[gnormhurst]

Originally Posted by Texan

Using a utility like Lint can help with those sorts of errors. Just run it and it will warn you of anything that you probably didn't mean to do.

Does the Microchip compiler have an option like Gnu's gcc "-Wall" (warnings: All)? I really miss -Wall. It catches when printf has the wrong number or type of arguments, warns about "if ( x = 0 )", and points out unused variables, for example.

I'm going to a talk by Brian Kernighan next week -- I'll give him your regards!

[Mark McLeod]

Originally Posted by gnormhurst

Does the Microchip compiler have an option like Gnu's gcc "-Wall" (warnings: All)? I really miss -Wall. It catches when printf has the wrong number or type of arguments, warns about "if ( x = 0 )", and points out unused variables, for example.

I'm going to a talk by Brian Kernighan next week -- I'll give him your regards!

In MPLAB look under Project->Build Options...->Project
under the MPLAB C18 tab "Diagnostics level" you can chose "errors, warnings and messages" and get more dianostic info, but it won't catch it all.

[Alan Anderson]

Originally Posted by gnormhurst

I'm going to a talk by Brian Kernighan next week -- I'll give him your regards!

If I recall correctly, K&R page 101 gives the derivation for the "canonical" string copy statement.

while(*t++ = *s++);

That's part of why I find c such an uncomfortable language to use. It wants me to think like a compiler. It encourages the use of simple shortcuts that a moderately well-designed compiler should be doing for me. My code is full of explicit tests for zero/nonzero. Although I know I could replace

if ( my_timer == 0 )

with

if ( !my_timer )

and get the same job done, I'm a programmer, and I want to be free to focus on the algorithms and let the compiler care about the details of the bits and bytes. Coding can be, and should be, done by machines.

And don't get me started on how numeric operations are performed using the smallest size that the operands will fit in, leaving me to worry about overflows even if I know the end result of an expression will always fit in the variable I'm putting it in. Oops, too late...

I apologize. It was a late night last night. And I must admit that the tool does get the job done, with little to no fuss, as long as I remember to use it correctly.

[gnormhurst]

Originally Posted by Alan Anderson

while(*t++ = *s++);

Yeah, that's just obscene. There are still programmers who seem to have the anti-social impulse to create clever, opaque code, so they can feel smug as the rest of the world struggles to understand what the heck it does.

[Ryan M.]

Originally Posted by Mark McLeod

In MPLAB look under Project->Build Options...->Project
under the MPLAB C18 tab "Diagnostics level" you can chose "errors, warnings and messages" and get more dianostic info, but it won't catch it all.

Personally, I find the messages more annoying then helpful. Some people might like it, though.

[Ryan M.]

Originally Posted by Alan Anderson

If I recall correctly, K&R page 101 gives the derivation for the "canonical" string copy statement.

while(*t++ = *s++);

That's part of why I find c such an uncomfortable language to use. It wants me to think like a compiler. It encourages the use of simple shortcuts that a moderately well-designed compiler should be doing for me. My code is full of explicit tests for zero/nonzero. Although I know I could replace

if ( my_timer == 0 )

with

if ( !my_timer )

and get the same job done, I'm a programmer, and I want to be free to focus on the algorithms and let the compiler care about the details of the bits and bytes. Coding can be, and should be, done by machines.

And don't get me started on how numeric operations are performed using the smallest size that the operands will fit in, leaving me to worry about overflows even if I know the end result of an expression will always fit in the variable I'm putting it in. Oops, too late...

I apologize. It was a late night last night. And I must admit that the tool does get the job done, with little to no fuss, as long as I remember to use it correctly.

As C/C++ is the language I know best, I don't find a statement like that very confusing. But I agree with you that it should be clear, not "clever." Even though I could read that perfectly, if anyone else looks at my code they might not be able to. It is better to write clear, obvious code, than to have a single line that does the exact same thing.

--EDIT--
P.S. Sorry for double posting there.

[deltacoder1020]

Originally Posted by Alan Anderson

If I recall correctly, K&R page 101 gives the derivation for the "canonical" string copy statement.

while(*t++ = *s++);

That's part of why I find c such an uncomfortable language to use. It wants me to think like a compiler. It encourages the use of simple shortcuts that a moderately well-designed compiler should be doing for me.

hence the reason for the string.h functions in any standards-compliant C distro. MPLAB is far from standards, as it is basically on the bare minimum needed to program a robot (which isn't going to be doing much with strings).

My code is full of explicit tests for zero/nonzero. Although I know I could replace

if ( my_timer == 0 )

with

if ( !my_timer )

and get the same job done, I'm a programmer, and I want to be free to focus on the algorithms and let the compiler care about the details of the bits and bytes. Coding can be, and should be, done by machines.

i'll agree with you on that - MCC18 is a fairly sucky compiler. there are, however, quite a few C compilers that do perform optimizations such as this. don't blame the language, blame the compiler.

And don't get me started on how numeric operations are performed using the smallest size that the operands will fit in, leaving me to worry about overflows even if I know the end result of an expression will always fit in the variable I'm putting it in. Oops, too late...

again, a fault of MCC18, not C itself.

all in all, most of the faults you described are with this specific implementation of C. Chances are you would find programming for a regular computer with C much nicer.

[velocipenguin]

C is one of my favorite languages. While it can be VERY unforgiving at first, it's not too difficult once you get used to the language. I used to make lots of simple errors (forgetting parentheses, failing to end statements with semicolons, etc.), but the frequency of that sort of error decreases significantly once correct C syntax becomes habitual. C is tremendously powerful without being nearly as arcane as assembler; it allows one to easily combine useful low-level operations with high-level procedural and algorithmic code in a syntax that's clear and human-readable. It took me a long time to get used to C, but I now find that it's my language of choice for many programming tasks. Don't blame the language because you made an error. Certain errors may look like obvious mistakes once you find them, but those errors are often similar or identical to operations that one might perform in order to obtain useful results.

For example:

if(file_handle = fopen("foo.bar","r"))
{
       herr_doktor_function();
}

That's a valid use of the single equality sign in a conditional. It checks to make sure the fopen was successful before executing herr_doktor_function. This could be written in a slightly clearer way, but it's a good example of why C has such lenient error-checking.

[Alan Anderson]

Originally Posted by velocipenguin

Don't blame the language because you made an error. Certain errors may look like obvious mistakes once you find them, but those errors are often similar or identical to operations that one might perform in order to obtain useful results.

Actually, that's exactly why I dislike c as much as I do. A small error in typing results in something which is both valid code and completely different from what I intended. A common and easily made error should be noticed as an error by the compiler.

Yes, c is very capable. It is also very terse. In sufficiently skilled hands, that's a powerful combination. In just slightly less skilled hands, it's a recipe for subtle errors. As for me, I prefer to use a language which is a bit less terse, with syntax that doesn't make it quite so easy to shoot yourself in the foot.