Re: g++ on embedded platforms

["John (Eljay) Love-Jensen" <eljay at adobe dot com>]

Hi arnuld,

Your questions are a bit off-topic for this forum.  Not saying that to
chastise, rather that you may get more answers of better quality on a more
appropriate forum.

That being said...

> At the company where I work, its decided by higher authority that we
> will use C since our software will run on some embedded platforms and
> for embedded platforms C++ is not a good idea.

I have done embedded programming with C and C++.  Long time ago.

Your company's higher authority is not "wrong", per se.

C++ for embedded platforms has some sharp, sharp edges that are generally
unimportant on (say) a personal computer, workstation, minicomputer,
mainframe, or supercomputer (except for the tight blazing performance
sections).

The sharp edges with C++ that can make it a poor choice for embedded
programming are (as I vaguely recall):
+ exception handling and RTTI can be too much overhead
  (in my situation, we used the compiler flag to disable exceptions
   and RTTI)
+ I/O streams?  ha ha ha ha ha ha
+ template magic can balloon the footprint

There may be other considerations too, which I have forgotten, or can't
recall at the moment (haven't had my caffeine dosage yet).

All of the above can be mitigated by having very skilled C++ developers, who
are aware of the potential pitfalls of C++ in an embedded platform.  And
they conscientiously avoid those pitfalls, and have a rigorous testing and
checking build system to ensure that something didn't sneak in and cause
things to go all pear-shaped.

But that's the trick... having very skilled C++ developers.  And if you have
very skilled C++ developers, it is not unreasonable to assume that they are
also very skilled C developers.

For an embedded platform, C has less surprises, and requires less rigorous
diligence to avoid the C++ pitfalls in an embedded environment.

In my experience, I think of C as a very pleasant macro-assembler language
(I came to C from an assembler background in 6502 and 680x0).

Whereas I think of C++ as an object-oriented language and an EXTREMELY
AWKWARD code generator language (i.e., template magic).  I've been
programming in C++ since 1990.

> Reading Stroustrup's FAQs tells me the opposite:
> http://www.research.att.com/~bs/bs_faq.html

Given very skilled C++ developers who have mechanisms in place (code
reviews, automated build checks to detect unexpected binary footprint
growth) to prevent C++ pitfalls going undetected... sure.

What is *NOT* a reason to avoid C++ are these not-true-isms:
+ C++ is slower than C [bzzzt, wrong]
+ C++ has a bigger footprint than C [bzzzt, wrong]
  (It's a DANGER, but not an /a priori/ given)

Good C++ should match/rival good C, in terms of both footprint and
performance.  I would not expect good C++ to surpass good C, nor vice versa.
But, in my opinion, good C++ will be more maintainable than good C -- which
becomes an important factor if the code base becomes very large.  I do not
expect that the code for an embedded project to become very large, so I do
not expect that the C++ maintainability factor (assuming my admitted bias in
favor of C++ has merit) to be a significant factor.

And, of course, bad code can be written in any language.  All bets are off
if your comparison is bad C++ versus bad C.

> I am implementing a Priority-Queue (PQ) in C but I see C++ already has
> a template, a generic PQ implemented in Std. Lib. Hence I am not much
> interested in code-duplication, I am not interested in doing a work
> which has already been done in a much better than I will ever do. We
> are using gcc for our embedded platform, now I don't get it if gcc
> works on embedded platform then why can't we use use g++ ?

I'm GUESSING that your higher authority either is concerned that the
developers are insufficiently skilled C++ developers, and as such, would
inadvertently create C++ code that was either slow, and/or had too large of
a footprint, and/or relied on otherwise available C++ mechanisms that will
be disabled for an embedded environment.

> The embedded platforms we are working on will mostly be *NIX or much
> less vxWorks and very rarely something Windows based.

In my experience, writing portable C++ for a variety of Unix, Windows, and
Macintosh platforms, C++ can be portable.  But it isn't "free" or automatic,
the team has to be conscientious about portability issues.

And -- my goodness -- there are a lot of portability gotchas.

> Has anyone worked on embedded platforms before, may be he can tell if
> we can use templates over there and any other information will be
> appreciated.

Yes, in my embedded platform code, we used templates.  A *lot* of templates.
(We used a homegrown work-much-alike and inspired by Douglas Schmidt's ACE,
which is strongly template driven, as was our homegrown framework.)

The trick to preventing the binary footprint from ballooning, but still
having most of the advantages of C++ and templates, was to separate out
common code from the template, so that the template was a thin veneer over
code which handled void* parameters.  The template goo would often disappear
(optimize away), or be a very thin springboard routine to the heavy lifting
non-template void* parameter driven code.

We got static type safety, and template generic programming.  And a small
footprint.

We did have to give up on C++'s dynamic casting, exception handling, and
RTTI.

Sincerely,
--Eljay