Robert Ammerman wrote:

> I have always thought that the 'hidden overhead' argument against C++ in 
> embedded systems was a bit specious.
> 
> For example, given the two C statements:
> 
> a += b;
> a /= b;
> 
> The second has a lot more 'hidden overhead' than the first on many, many 
> architectures. Of course, anybody writing in C for a small system knows, 
> more or less instinctively, that division is more expensive than addition.
> 
> Well, I submit that an _experienced_, _knowledgeable_, C++ programmer has a 
> similar understanding of the overheads involved in C++ (things like virtual 
> functions and exceptions).

I agree. I think that the problem may be mostly that a standard-conform C++
compiler (and only such a compiler could really be called C++) has to
implement many such high-overhead constructs that only a small fraction of
users would use. This leads to implementing a lot of features for little
(economic) gain -- which I think is the reason C++ in this area is rare.


William "Chops" Westfield wrote:

> I'm still not sure I understand the point of C++ in small embedded
> systems (although I sorta like function overloading.)

There are a number of features in C++ that don't cause run-time overhead
and make programming nicer. Function overloading and (non-virtual) classes
are among them. But a compiler that provides these without the rest is not
a C++ compiler, and I'm not sure it's economically viable to implement all
the rest for the little use some of it would have.

Gerhard

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist