Chuck,
The question of if C++ causes too much bloat for embedded has been hashed
out numerous times on avrfreaks. The verdict -- in most cases it shouldn't
make the least bit of difference... given equal functionality. Some things
that cost more are:
1) Templates... sometimes. I've used templates extensively to allow for
safe ( compared to preprocessor magic ) compile-time polymorphism and have
suffered NO expansion in code size or execution time compared to a direct C
implementation. In other cases, templates can lead to extra program memory
usage, though, still, the same execution speed. Templates seem to be
pretty easy for the optimizer to grok.
2) Virtual functions. Run-time polymorphism requires an indirect function
call ( and commensurate increase in execution time ) and storage of the
vtable. The indirect function call would cost the same as if the
polymorphism were implemented directly in C with function pointers, so it's
not really an extra cost. Besides, the C++ polymorphism is so much cleaner
than a hacked together "polymorphic" C that it is difficult to argue
against C++ when polymorphism is desired. One annoying issue with vtables
( on the AVR ) is that they sit in RAM and, thus, use up an already
precious resource. Still vtables are small and not using virtual methods
gets rid of the cost entirely anyway.
3) Temporary variables. There are times that temporary variables sneak in
and disrupt the optimizability of code. Understanding the times that C++
might create such variables usually allows for designing the code to avoid
it, but sometimes there are surprises. Usually, however, the cost is
relatively minimal anyway.
For projects of any real size, I now use C++ exclusively on the AVR -- most
of my projects are on 8kB -16kB class devices and I rarely worry about
flash consumption. Granted, these tend to be very focused applications,
but I've done tests comparing to similar pure C implementations and the C++
is always with 10% for memory usage and, typically, even closer, for
execution speed.
Martin Jay McKee
On Tue, Nov 27, 2012 at 8:34 AM, Chuck Hackett <egroupscdh@up844.us> wrote:
> **
>
>
> Forgot one other question:
>
> Is it not advisable to use C++ for embedded AVR projects due to excess code
> size, etc.?
>
> When I say "excess" code size I mean unreasonable when taken in light of
> the
> advantages of C++ for encapsulation, etc., etc.
>
> I realize that the answer to this is different for different circumstances
> but just looking for a general guideline. I am willing to buy a larger
> processor to gain the advantages of C++ but I realize that there is a limit
> to this because of the limits of AVR memory space.
>
> I also realize that this is an area like ASM .vs. C: you can usually
> generate more compact and efficient code using ASM but there are advantages
> to using a higher level language such as C and each person/project has to
> weigh the pros & cons.
>
> I'm looking for comments such as one would make advising someone not to use
> "printf" in embedded projects (pulls in a lot of code and increases stack
> usage) - I use it for formatting debugging messages, etc. but realize that
> I
> might have to give it up if I get close to the code space limit.
>
>
> Cheers,
>
> Chuck Hackett
> "Good judgment comes from experience, experience comes from bad judgment"
> 7.5" gauge Union Pacific Northern (4-8-4) 844
> http://www.whitetrout.net/Chuck
>
>
>
[Non-text portions of this message have been removed]