Re: C++ for Embedded Systems.
John Carter wrote:
On Mon, 25 Sep 2006 15:20:25 -0400, P.J. Plauger wrote:
EC++ is alive and well.
What makes EC++ really advantageous is the smaller footprint library
that comes with it.
Thanks for your reply, I immediately went abrowsing through the
your website reading the EC++ library documentation.
And left feeling slightly bemused.
The one thing the EC++ library offers most of, is formatted stream
handling, and that is what we have least need of in an embedded
environment. (Read: None)
My hunch is that iostreams take up a lot of space in the footprint of a
C++ library. Thus, it would be important if space here could be
minimized. An alternative would be to avoid iostreams completely and
use a lightweight version instead.
The one thing the EC++ library offers that we need most is a string class,
but it doesn't offer wide char strings. (Which is one of the drivers for
changing our UI to C++ in the first place. Non-english language versions)
And since our programmers keep rewriting, relative to STL, poor and bloaty
C implementations of common containers. We need generic container
types, which EC++ doesn't offer at all.
This is because EC++ does not have suppport for templates. Templates
and exception handling are two features missing from EC++ - presumably
to reduce risk of code bloat and let programmers learn faster.
Unfortunately, this makes EC++ very different from C++ and lots of nice
stuff is suddenly missing (as e.g. your containers). I believe I would
recommend regular C++ in all but the tightest environments.
Last time (years ago), I poked about the internals of the gcc libstdc++
implementation I was impressed by the progress they had made in terms of
clamping down on template bloat. For example I seem to remember the
worker classes behind some of the fancier data structures were type
neutral (void *). ie. Instantiated once, with a thin veneer of inline type
casting on the outside. ie. Zero cost for more than one type instantiation.
Right. You can do that for some of the stuff. You could also rely on a
more advanced compiler to fold similar code whenever feasible. There
are compilers where e.g. std::vector<int>::push_back uses the same code
as std::vector<unsigned>::push_back and std::vector<void*>::push_back.
In fact I observed on average they did better than some of the handcrafted
implementations in our C systems.
Of course... if you only need one container you have the time to spend
more time optimising.
What I'm seeking guidance on is the usage of C++ / STL that "optimizes for
ram/rom size" rather than speed. Sort of like -Os for STL usage guidelines.
The other common requirement in embedded systems is determinancy. We need
to know, even more than in desktop / server apps, at design time the worst
case behaviour. (Which to me is an argument for using STL in embedded
systems.) However, a standard C++ gotcha is the time to process an
exception. A style guideline for embedded programmers should probably
highlight that in the appropriate context.
These are the sort of C++ vs Embedded gotchas and guidelines I'm seeking.
This requires detailed study/analysis of the given compiler. I am
afraid that I can't give you any advice here as this is compiler
specific and I don't have any experience with real time systems. But I
will recommend Comeau as a source for compilers and information - the
adress is http://www.comeaucomputing.com/.
Kind regards
Peter
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]