Why I hate c

[Astronouth7303]

PIC C isn't object oriented like MSC++, which means that you don't have classes and the code Object.Method(Args); is invalid.

[Chris Hibner]

Originally Posted by velocipenguin

I think you missed the point.

The reason C compilers don't typically give warnings or errors for using the single equals sign inside a conditional is because it CAN be valid. In the code I posted, the single equals sign sets the address of a file handle, whose value needs to be inequal to zero in order to work. Yes, it's one of those annoying tricks used by programmers who like being clever (i.e. me), but my point is that it's valid and there's no reason the compiler should label it as a syntax error.

You're right in that no compilers will list this as a syntax error. However, every C compiler that I have used (up until the compiler for the IFI RC) will give a warning for the type of statement that you describe using the default warning settings.

If you are using a new compiler, one of the first things you should do is see how the warning levels are set, and then set them to how you like them.

As people have been finding out, C allows a lot of "strange" things as valid syntax, which is done to increase flexibility and the speed of the language. However, this can lead to some confusing run-time errors. This is why C compilers have warning messages in addition to error messages. If you use the warnings properly, you shouldn't have much issue.

Another point: C is like anything else in life: you're not going to be good at it until you practice with it. You'll make errors, you'll find the errors, and then you'll start learning where to look for future errors. In the future, you'll begin to recognize certain behaviors that will help you pinpoint the errors. You know, "hey, I've seen this type of thing before".

Just because you've all hit a few stumbling blocks on your first attempt at C doesn't mean it's a bad language. It just means you're not used to it. Give it a little time and you'll soon be wondering how we ever survived with pBASIC.


Also: Has everyone been taking advantage of signed math? I sure hope so. It is probably the biggest advantage of the new C compiler vs. the old pBASIC controller.

[Astronouth7303]

My first roadblock in learning C(++) was the complexity and the amount of "Valids" vs. "Invalids".

Haven't needed signed math. Well, I did write an abs() function for variance stuff.

[Joe Johnson]

Originally Posted by Astronouth7303

My first roadblock in learning C(++) was the complexity and the amount of "Valids" vs. "Invalids".

Haven't needed signed math. Well, I did write an abs() function for variance stuff.

Signed Math is the one thing that I get down on my knees and give thanks for every time I open our code.

If you are doing any serious control loops (a PID feedback control on a robot arm for example), signed math is a real time saver.

But... ...C is a language for consenting adults. You can get into a lot of trouble if you are a casual user.

Joe J.

[Jay Lundy]

Originally Posted by Chris Hibner

Also: Has everyone been taking advantage of signed math? I sure hope so. It is probably the biggest advantage of the new C compiler vs. the old pBASIC controller.

Yeah, signed math is such an incredible improvement. Not to mention the increased data memory! I used to never use 2 byte variables in PBASIC, now I use ints all the time (well, when necessary... which is quite often).

I like C because it let's you do so much, though I agree the single = sign in if statements should probably throw a warning. But I've used it so much now I can usually trace errors like that fairly quickly (or avoid them altogether).

[Jim Zondag]

All the above discussion is exactly why here in my world, we don't write software by hand any more. It is easy to produce bug free C code that does exactly what you want every time if you have the right software tools. We use an Autocode generator called Rhapsody by I-Logix to generate all of the code we use for the interior systems of all DaimlerChysler vehicles. We write code in a graphical state-machine format and the code generators translate these models into embedded C. In the near future, most software will be developed this way. Now that we have moved from Pbasic, we can apply these methods to robots. I autogenerated the software module for my shift scheduler on BUZZ9 and it dropped right in.

[Chris Hibner]

Originally Posted by Jim Zondag

All the above discussion is exactly why here in my world, we don't write software by hand any more. It is easy to produce bug free C code that does exactly what you want every time if you have the right software tools. We use an Autocode generator called Rhapsody by I-Logix to generate all of the code we use for the interior systems of all DaimlerChysler vehicles. We write code in a graphical state-machine format and the code generators translate these models into embedded C. In the near future, most software will be developed this way. Now that we have moved from Pbasic, we can apply these methods to robots. I autogenerated the software module for my shift scheduler on BUZZ9 and it dropped right in.

We handcoded our IFI RC. However, we autocoded most of our autonomous code running in our off-board processor (we did this last year as well). We use TargetLink by dSPACE. This software takes block diagrams and state-machines made with Simulink and Stateflow (part of Matlab by the Mathworks) and auto-codes them. We've had great success doing it this way. (As a side note, we use this software to auto-code some algorithms for production at TRW.).

[Joe Johnson]

Originally Posted by Chris Hibner

We handcoded our IFI RC. However, we autocoded most of our autonomous code running in our off-board processor (we did this last year as well). We use TargetLink by dSPACE. This software takes block diagrams and state-machines made with Simulink and Stateflow (part of Matlab by the Mathworks) and auto-codes them. We've had great success doing it this way. (As a side note, we use this software to auto-code some algorithms for production at TRW.).

Mathworks (makers of Matlab & Simulink & Stateflow - perhaps the world's largest/most popular simulation software company) is right outside of Boston in Natick. The founders seem like Dean & Woodie kind of guys -- visionary folks.

Does anyone within the sound of my voice have an "in" with Mathworks?

I know this would be a huge huge huge step forward in terms of programming robots. Think of how easy it would be to program if you actually had models of arms, motors, Victors, Spikes, valves, cylinders, etc. all ready and waiting for you to drag and drop? You could code your robot before you actually had a robot in stead of what we have now which is the mechanical system gets done in 5.9 weeks, the wiring gets done in .09 weeks and the programmers have .01 weeks to make it all behave.

There are a lot of things that are unfair about the FIRST competition, but the stress that we tend to put on the coders is among the unfairest burdens we put on people in this FIRST game.

If anyone can get Mathworks to fall in love with FIRST, we would be a long way to making it up to our poor coders.

Joe J.

[Kevin Sevcik]

Heh, this is possibly off-topic since the thread has wandered slightly from hating C, but here's a beautiful piece of C code and explaination that I snatched from the hacker's dictionary.


Duff's device: n.

The most dramatic use yet seen of fall through in C, invented by Tom Duff when he was at Lucasfilm. Trying to optimize all the instructions he could out of an inner loop that copied data serially onto an output port, he decided to unroll it. He then realized that the unrolled version could be implemented by interlacing the structures of a switch and a loop:

register n = (count + 7) / 8;      /* count > 0 assumed */
switch (count % 8)
{
case 0:        do {  *to = *from++;
case 7:              *to = *from++;
case 6:              *to = *from++;
case 5:              *to = *from++;
case 4:              *to = *from++;
case 3:              *to = *from++;
case 2:              *to = *from++;
case 1:              *to = *from++;
                   } while (--n > 0);
}

Shocking though it appears to all who encounter it for the first time, the device is actually perfectly valid, legal C. C's default fall through in case statements has long been its most controversial single feature; Duff observed that “This code forms some sort of argument in that debate, but I'm not sure whether it's for or against.” Duff has discussed the device in detail at http://www.lysator.liu.se/c/duffs-device.html. Note that the omission of postfix ++ from *to was intentional (though confusing). Duff's device can be used to implement memory copy, but the original aim was to copy values serially into a magic IO register.

[For maximal obscurity, the outermost pair of braces above could actually be removed — GLS]


Heh. Took me a minute to wrap my head around it, but I think it's nifty.

[Alan Anderson]

Originally Posted by Kevin Sevcik

...a beautiful piece of C code...Duff's device:...

Beauty is in the eye of the beholder. So, apparently, is ugly. Duff's Device is clever, but it goes back to my old comment about c wanting the programmer to "think like a compiler". Optimizations like this should be done in the compiled code, not the source code.

I guess my discomfort with c boils down to the fact that it's a low-level language in high-level language clothing. It's not far removed from assembly language. I do understand the reason for its being that way. That doesn't mean I have to like it.

[deltacoder1020]

Originally Posted by Alan Anderson

Beauty is in the eye of the beholder. So, apparently, is ugly. Duff's Device is clever, but it goes back to my old comment about c wanting the programmer to "think like a compiler". Optimizations like this should be done in the compiled code, not the source code.

I guess my discomfort with c boils down to the fact that it's a low-level language in high-level language clothing. It's not far removed from assembly language. I do understand the reason for its being that way. That doesn't mean I have to like it.

it's really a mid-level language. things like Visual Basic are high-level languages, assembly is the ultimate low-level language... C is a mixture of the two. functions, for instance, are above a low level language, as is order of operations, complex conditionals, et cetera. Instead of "having the compiler do all the optimization", however, C takes the route that the ultimate optimizer is the human mind - a compiler can only do so much optimization, but a human can always invent new innovative ways to optimize something.

[Ryan M.]

Originally Posted by deltacoder1020

...a compiler can only do so much optimization, but a human can always invent new innovative ways to optimize something.

Good point. And most compilers to try to optimize some stuff, but there is always situations where the compiler doesn't have the optimization built in, but the human sees that it can be better and does the optimizations on his/her own.

[The Lucas]

Originally Posted by Joe Johnson

Mathworks (makers of Matlab & Simulink & Stateflow - perhaps the world's largest/most popular simulation software company) is right outside of Boston in Natick. The founders seem like Dean & Woodie kind of guys -- visionary folks.

A Mathworks partnership would be an amazing asset to all programmers around the FIRST World. Imagine testing all your Autonomous programs without a finished robot or a practice field, which most coders don't get till Thursday of their first regional.

It is my understanding that Mathworks is still privately owned (ie no stockholders) so it may not be that difficult to get the owners, who are programmers themselves, to agree to help FIRST. They already heavily support academics since MATLAB really got its start in universities.

Great Idea Joe! Hope some one can follow through on it.

[velocipenguin]

Originally Posted by Alan Anderson

Optimizations like this should be done in the compiled code, not the source code.I guess my discomfort with c boils down to the fact that it's a low-level language in high-level language clothing. It's not far removed from assembly language.

Tweaking code for maximum efficiency is a useful skill to have. Coding for small microcontrollers, regardless of the language used, requires a fair amount of manual adjustment to make everything fit. Although I suspect this is rather uncommon, I actually enjoy this; it's a tremendously entertaining challenge to try to cram complex routines into the tiny program ROM on low-end PICs. If you want a language that hides all the scary details from you, code in PBASIC. C is a little harder to deal with, but it offers far more control over the hardware than anything else (except assembler, of course).

[Chris Hibner]

Originally Posted by velocipenguin

Tweaking code for maximum efficiency is a useful skill to have. Coding for small microcontrollers, regardless of the language used, requires a fair amount of manual adjustment to make everything fit. Although I suspect this is rather uncommon, I actually enjoy this; it's a tremendously entertaining challenge to try to cram complex routines into the tiny program ROM on low-end PICs. If you want a language that hides all the scary details from you, code in PBASIC. C is a little harder to deal with, but it offers far more control over the hardware than anything else (except assembler, of course).

This is a great point. C's strength is in making highly efficient code for embedded control systems. That is one reason that I like having C for the controller this year: it gives people a good feeling for what it's like to program a real embedded controller.

As I've mentioned before, things are starting to move more toward auto-coding, but this is made possible due to faster, cheaper microcontrollers that can make up for the more inefficient code. However, there is still a high likelihood that we'll be using C for quite a while since there will always be an ultra-cheap product that needs to have too much code crammed into a tiny micro.

One last thing about auto-coding: Auto C code generation is just another step up the auto-coding ladder. It's not that revolutionary. Think about it: what is a C compiler other than an auto-coder for assembly language? People used to program with only an assembler. Now the standard is to let the C compiler auto-generate the assembly code and THEN let the assembler go ahead and make the machine code. The next level up is to let TargetLink create the C code, then the compiler creates the assembly code, and so forth.