"Before you get too carried away badmouthing what has evolved to the point where geniuses like you are now involved, remember those were the ones that made it work while others were off inventing computer science. They had a job to do and not the luxury of waiting for computer science to mature."

I respect programmers from 20 years ago who didn't have modern tools at their disposal. I WAS a programmer 20 years ago. (And back then I did many of the things I would now consider bad programming, sometimes out of necessity, sometimes because I just didn't know what the h I was doing.)

The point is I move on and TRY to stay up to speed. A doctor who still runs around amputating limbs because he never trusted antibiotics is just a bad doctor. It doesn't matter if we're talking about the guy who invented the bone saw, I still want the doctor with the antibiotics to treat my infection. And in 20 years I'll want the guy who knows how to operate the germ-zapping quantum laser.

But it's all completely irrelevant to the fact that the myths about C++ prevalent in the embedded community have very little truth to them.

"I would sure like to see the hardware that you designed. Also in your spare time would you whip up a hardware simulator that can be used to check out functional behavior in the early stages of design?"

And this I think goes a long way towards explaining where those myths come from.

"One last thing. Since the compiler does whatever it wants, how do you know if code execution time meets the hardware timing requirements?"

A C++ compiler doesn't do whatever it wants. It does exactly what you tell it to do, but compared to C, C++ gives you a larger vocabulary with which to communicate those intentions. You're still free to fall back on just the C subset of C++ when some of that automated (not spontaneous) code generation could cause unpredictable timings. You're even free to include a bit of inline asm where you feel it's appropriate.

Again, a plain-C compiler will still do things you might not expect if you don't know what you're doing. For instance, does this cause a delay?

int i;
for( i = 0; i < 1000; ++i ); Does this allow you to detect an array overrun? int array 100 ;
int overrun_check = 0;
some_difficult_function( array );
if( overrun_check ) ...

In both cases an asm-accustomed programmer with little knowledge of C might not understand how the compiler optimises stuff away and automatically lays out variables on the stack. A C compiler can insert code, too. Just use floats on any system that doesn't have an FPU, and count yourself lucky if the compiler warns you that all the float math is really being emulated in integer arithmetic.

Bottom line is, if you don't understand the tool you're using, the results may surprise you. If you do know C++, however, there is no mystery to it. It only automates operations, it doesn't have a mind of its own.

Ok I cannot muster enough energy to debate this futher, but I found an amusing detail related to this discussion from another article on this site, namely the one regarding a publication "Software for Dependable Systems" found here:

http://www.embedded.com/columns/breakpoint/220900315

Note that the book mentioned solely addresses safety-critical systems, and thus not generic embedded apps. This book is written by a committee consisting of numerous experts. They address a number of "best practices", where they explicitly warn against inheritance:

"Inheritance is a powerful but dangerous programming feature. Use it sparingly, and whenever possible favour composition (adding functionality by embedding one object explicitly in another) over inheritance. Design for inheritance or prohibit it, and do not extend classes that were not designed with extension in mind. In critical applications, avoid inheritance or ensure that adequate time has been allowed for the extensive additional verification activity that will be required."

This is an interesting opinion. As I wrote in my previous post, I mainly avoid inheritance for complexity, productivity and performance reasons. I have not really regarded it as a potential hazard before, but I guess it is all related. Inheritance adds complexity and program dependences, two factors that the book point out as common causes of disasterous software failures.

The most interesting about this remark is: Just because C++ has a feature that C lacks, it doesn't automatically mean that this feature is equivalent with good program design. It may very well be the opposite. This is what I've been preaching throughout this discussion. Good program design is in most cases language independant.