C++ in embedded systems - Page 3

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: C++ in embedded systems

Quoted text here. Click to load it


That's definitely possible to predict what code a C++ compiler might
generate from various construct.
I've been doing that for more than 12 years - approximate half of that time
developing embedded systems.
The embedded systems where mostly with performance compareable to a 16 Mhz
80386, 2 MByte ROM, 2 MByte RAM.

Quoted text here. Click to load it

Of course there are "some embedded environments" where C++ is inappropriate.
The same is true for all languages.
It can be because the target machine have very limited resources and _very_
tight control is requiered.
It can also be because of some company policy which specifies the use of
another language.

The C++ language can be understood and used effectively in embedded
It takes skills and care to write high performance code in any language.
Educations and understanding is a prerequisite for using C++ effectively,
but there are a lot of sources to learn from.

Kind regards

Mogens Hansen

Re: C++ in embedded systems
snipped-for-privacy@visi.com (Grant Edwards) wrote in

Quoted text here. Click to load it

Which, in essence, is exactly what I said in the paragraph
preceding the one you quoted, and which you conveniently snipped.


Do not send e-mail to the above address. I do not read e-mail sent there.

Re: C++ in embedded systems
snipped-for-privacy@yahoo.com (Mad@Spammers) wrote in message
Quoted text here. Click to load it

You should check out the Rationale for Embedded C++.  It gives a good
overview of which standard C++ features were left out and why.


I think they drew a pretty good line about which features are and
aren't useful for embedded systems.  Although I don't understand why
they felt it was necessary to eliminate wchar_t.

Re: C++ in embedded systems

Quoted text here. Click to load it

EC++ might be correct to leave out RTTI and C++ EH, but disagree with some
of the other decisions. The assumption seems to be that embedded developers
are not as competent as desktop developers and that embedded software is
much simpler (I'm thinking of mutable ["it might confuse them"] and
namespace [embedded software isn't big enough]).

Re: C++ in embedded systems

Quoted text here. Click to load it

eC++ dumbs down the language under the pretense that embedded programmers
are too stupid to properly use the deleted features.  In reality, I think
eC++ is a cop-out by compiler vendors who can't keep up with GNU.  They want
to change the rules for the sake of their marketing departments.

Re: C++ in embedded systems
snipped-for-privacy@aol.com (Dingo) wrote in

Quoted text here. Click to load it

Personally, I subscribe to the view that EC++ was concocted by
compiler vendors in order to create a market for their non-Standard-
compliant C++ compilers.

I find many aspects of the rationale downright insulting, making
direct or indirect references to embedded system developers' supposed
limited ability to comprehend C++.

The removal of templates, exceptions, and RTTI is arguably justified
on the grounds of efficiency although, as has been pointed-out elsewhere
in this thread, any half-decent C++ compiler will allow the user to
disable those anyway.

On the other hand, perhaps someone can explain why "mutable", namespaces,
and the C++-style casts were removed, if not to make the compiler-
writers' lives easier.


Do not send e-mail to the above address. I do not read e-mail sent there.

Re: C++ in embedded systems

Quoted text here. Click to load it

Yes, my point exactly; that's what I meant by "to make compiler-
writers' lives easier." But that is not an argument invoked by
the EC++ rationale.

There are many other things that could be removed from C++ that
would have a much greater impact. What a coincidence that the
things that were removed are largely things that were late additions
to the C++ Standard and that therefore would have required extra
effort to be supported by pre-Standard compilers.

I don't care if vendors want to subset C++ out of desire to
sell their sub-Standard compilers to developers. I _do_ care when
they spread FUD about C++ in order to do it. These deletions in
no way make EC++ better able to "fulfill the particular requirements of
embedded systems designs" than full C++.

Quoted text here. Click to load it

"mutable" is also indispensible in certain circumstances to allow
for const objects, and const objects are very useful in leveraging
the C++ type system to assist in making code more reliable.

Quoted text here. Click to load it

static_cast, const_cast, and reinterpret_cast have nothing to do with
RTTI. Only dynamic_cast is related to RTTI.

On the other hand, static_cast and const_cast do make a program more
reliable and more maintainable by working within the compiler's type
system, instead of bypassing it, as C-style casts do.

Quoted text here. Click to load it

Both C and C++ define numerous different symbol scopes, so I have a
really hard time believing that namespaces will slow anything down

Quoted text here. Click to load it

Visual C++, for one, allowed this long before EC++ came along, and
I'm sure that others did too.

Quoted text here. Click to load it

How does EC++ make this easier than a simple line of text in the
description of the library that would state "does not use exceptions
or templates"?


Do not send e-mail to the above address. I do not read e-mail sent there.

Re: C++ in embedded systems

Quoted text here. Click to load it

...And/or RTTI.  You were completely write about all C++ style casts.
Only dynamic cast is requiring RTTI support.  I believe GCC will
automatically warn about this if -fno-rtti is used.  I guess this
should be implicit.

I think that having the Standard does help to quantify what library
facilities are used.  Does the average programmer have time to
quantify every aspect of the language.  Getting the compiler options
correct with a binary only distribution can be problematic.

I would be much more likely to buy/use a library that was Embedded
'C++' compatible.  Even after reading the working groups paper on C++
performance, I think that exceptions are too expensive for my embedded
devices with the compiler that is bundled with the OS.  In fact I
believe that stack tracing and tables will alway be more expensive in
code space than letting a watch dog go.  In the WG21 paper sighted,
the exit/reset on error conditions didn't seem to be compared to EH
overhead.  Exit/reset on error are often used for simplicity and
safety in embedded systems... at least that has been my experience,
but maybe I am some sort of horrible barbarian.

I do think that at some point linkers and compilers will become mature
enough ( and host computers will be fast enough) that templates will
be useable and beneficial in the embedded space.  But I have never
seen a compiler that handle templates well enough for my needs.

Of course you can explicitly spell out every condition that a library
adheres too, instead of just saying "Embedded C++ compliant".  Just
like you can do everything in assembly that you can do in C++.

Bill Pringlemeir.

If I gave a damn, you'd be the first person I'd give it to.

Re: C++ in embedded systems

Quoted text here. Click to load it

Namespaces are just a formal way of specifying how to decorate 3rd party
API's with a vendor's name to avoid collisions. Removing them causes
additional code clutter as one is forced to decorate every point of usage
(eg. "vendor27_do_something()"). (With namespaces, one uses a using
statement at the top of a block to identify which vendor's API's are in
force for that block.)

If you use no 3rd party code (including libraries developed by other teams
within your organization), namespaces are admittedly superfluous.

Kenneth Porter
http://www.sewingwitch.com/ken /

Re: C++ in embedded systems
Quoted text here. Click to load it

I happen to disagree; that line isn't clearly and cleanly drawn (or
could be in general). That "rationale" is pretty old and concerns
other than safety in embedded systems (such as the availability of
in-house-built C++ compilers) influenced the decisions.

For a different and somewhat contrary view, have a look at the ISO C++
standards committees TR on peformance issues:

  - Bjarne Stroustrup, http://www.research.att.com/~bs

Re: C++ in embedded systems
Quoted text here. Click to load it

Strange statement, which of course I totally disagree with ;). I do OO in C
and assembler all the time. With real projects. I have no desire to use C++.
OO is a design issue, not a coding issue. (C++ is not just a coding
language - it could be considered a very much higher-level language than
C++, and indeed that's part of my problem with it.)

However I guess a) you would imply that I'm not using OO "well" and b) it
depends on exactly how you define OO. I use OO in the sense of
encapsulation, data-hiding, polymorphism, inheritance etc. I don't use all
the other gubbins that tends to get associated with it e.g. operator
overloading, multiple inheritance, etc. I use the features that benefit
clarity and maintainability, and avoid those that adversely affect them.

Here's briefly/roughly what I do:
  - one class per module (usually defined as a private struct of member
variables and function pointers)
  - no project-global variables (ony the interface member functions are
  - polymorphism involves passing one more variable (which effectively is
the index for a state machine)

Not hard.

Quoted text here. Click to load it

The need for discipline is true of all design, surely? Once mastered, why
can't it be sustained?


Re: C++ in embedded systems

Quoted text here. Click to load it

C++ is often criticized because it is bloated and too complex.  The K&R
book, complete with tutorial, is about 200 pages.  A good C++ book is
well over 1,000.  How can anyone actually master a language like that?

C++ started out with a good idea and then tried to become all things to
all programmers. Now, does that mean that we should dump C++?  Think
about the logical progression of languages.  In the beginning we had
data items, then arrays of like-kind data items, then structures of data
items of differing kinds and sizes.  The next step is simply a structure
that not only contains the data items, but also the functions that
operate on that data.  We call that a class.

The class should be used for the same reasons that you would use a
structure; it clumps things together.  Is it a necessity? No; you could
clump things together using separate files.  An example of this in C is
FILE.  It is an I/O structure with all of the functions, such as fopen,
needed to operate on the data. Although using classes is not a
necessity, neither is the use of a structure.  Try writing a C program
without using a structure.

Now about your issue of the difficulty of optimizing after the fact.
Tony Hoare stated, and restated by Donald Knuth: "Premature optimization
is the root of all evil".  The original quote was, "We should forget
about small efficiencies, say about 97% of the time: premature
optimization is the root of all evil."   Why optimize until you know
where the bottle neck is?

I came from the era when all embedded code was written in assembly;
processors just weren't fast enough.  Now the processors are faster and
the compilers are better.  I now write in C, C++ and assembly.

The most important thing to remember is that we write programs to make
money.  A programmer who doesn't use the tools of the time will take
longer to market and loose revenue.  Just write good code, know when to
use C, C++, assembly,  and know when to use which tools.  You don't want
to become one of today's programmers who need a PC with the speed and
horse-power of yesterday's Cray Super computer just to run a simple word

Marty Pautz

Re: C++ in embedded systems
Quoted text here. Click to load it

   The most important optimization is done during DESIGN!  Proper choice
of algorithms is BY FAR more important than bit twiddling.

Quoted text here. Click to load it

I have also been in the business for a while and use many languages
(hopefully choosing the right one) and love BOTH C++ and Forth.  Properly
written C++ is more efficient than C, and Forth can create the smallest
ROM image.  It depends on what you are trying to optimize!


Re: C++ in embedded systems
Quoted text here. Click to load it
... snip ...
Quoted text here. Click to load it

Replacing a few words in your statement, we have: "doing hi-level
programming in a non-hi-level language demands ..."  This applies
to using assembly, and equally to using C.

The better programmers in both languages impose exactly that sort
of discipline on themselves, and get very irritated at languages
that do not allow them to ignore those disciplines when needed.
Unfortunately many such programmers have a poor perception of
'when needed' and thus leave many incipient bugs and insecurities.

The C programmers attitude to Pascal, and the inverse, are
examples.  The languages are highly similar, with very similar end
capabilities.  Escape hatches in Pascal need to be carefully
thought out to preserve reliability.  External routines, file
drivers, etc. come to mind.  A system which allows controlled
intermixing is Ada.

Chuck F ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.
Re: C++ in embedded systems

Quoted text here. Click to load it

Modula-3 is another good example.

Grant Edwards                   grante             Yow!  My uncle Murray
                                  at               conquered Egypt in 53
We've slightly trimmed the long signature. Click to see the full one.
Re: C++ in embedded systems

Quoted text here. Click to load it

I think I have met 3 of them.

Re: C++ in embedded systems
Quoted text here. Click to load it

As a C++ developer for embedded systems with some twenty years of toil
behind me, I have nothing but respect for Forth developers. I envy the fact
that they can develop interactively and be running code on new hardware in
minutes. We have many more obstilces in our way (compiler, linker, debug
target, download agent, debug client; all of these have to work before
anything works). We work far from the hardware; forth developers are in
contact with it.

Quoted text here. Click to load it

Re: C++ in embedded systems

Quoted text here. Click to load it
Tee hee. But if it was true, I would have been out of business
long ago. Modern Forth compilers produce good code, and where
code density matters, Forth still produces applications that
are often half the size of C applications. And yes, I do
have numbers to back this up for a payment terminal (8051)
and an embedded web server (68xxx, H8S and ARM).

Quoted text here. Click to load it
Very true. I would also add that with the exception of web weenies,
very few junior programmers have used any languages other than
C/C++ and perhaps Java. This in distinct comparison from 15 years
ago, when most programmers in any field had actually used a
much wider range of languages and had the experience to be able
to select an appropriate language for a job. If you have never
used interactive languages, you will never be able to appreciate
what they have to offer. Remember Smalltalk, Eiffel, BASIC ...
Any community misses out if its focus is on a range of culturally
similar languages, programming or spoken.

Quoted text here. Click to load it
Apart from OO (the current silver bullet), there is little to
separate any of the batch compiled languages such as C, C++,
Pascal and so on. At least Modula 2 dealt with the dependency

Quoted text here. Click to load it
It is August and the silly season is upon us :-)


Stephen Pelc, snipped-for-privacy@mpeltd.demon.co.uk
MicroProcessor Engineering Ltd - More Real, Less Time
We've slightly trimmed the long signature. Click to see the full one.
Re: C++ in embedded systems
In most "embedded designs," I either use assembler or C++ and assembler.  In
particular, GCC's in-line assembler is extremely powerful (once you get the
hang of it).  In my experience, I have not run across any situation where I
could find a performance advantage between C and C++ -- if the processor has
the architecture and performance headroom to support C it will also support

The C++ advantages and drawbacks are like everything else in a tight
design -- you have to be sure you can afford the convenience.  This judgment
comes from experience, and it may be that most C++ programmers work in the
user application space where efficient coding often does not bring
performance advantage to the overall enterprise system.  After all, if you
are shoveling megabytes XML across your 1.544 mb/s internet connection, who
gives a flip whether you tighten up some inner loop with hand done assembly
language?  But for real embedded work, where you are trying to shoehorn the
product into the cheapest microprocessor with the fewest resources, here are
some advantages over C that C++ brings to the table:

1. Classes.  It's very nice in embedded systems to organize pieces of
hardware into objects.  For instance, in a very tight AVR project where I am
counting cycles, I have a class that wraps the SPI port with an interrupt
handler, several command methods, a foreground routine, and logic code to
generate and decode packets sent to/from an FPGA.  I did it this way to make
it simple for me and the FPGA designer to stay on the same page, even
editing each others code.  But after we were done, I abandoned plans to
tighten up its performance.  It is better than I could do with straight
assembler, and it's more than fast enough.

2. overridden new/delete operators.  I can override new and delete
operators, swapping in a custom memory manager to replace "stock" dynamic
memory (malloc/free) support.  In designs where I need dynamic memory, but
can't afford a heap, this is a very nice way to get screaming performance in
a manner transparent to the application.

In my experience, here are some C++ features that may or may not be helpful:

1. Multiple inheritance.  This adds a lot of code and overhead to function
calls as your "this" pointer is transparently moved about.  In some cases, I
have used sloppy multiple inheritance to get a prototype running, but after
profiling, gone back and replaced some of it with explicit code.  However,
when simple member functions can be implemented inline, then the optimizer
usually completely removes the overhead.

2. Virtual Functions.  If you're playing tricks in C with function pointers
to add abstraction, sometimes C++ virtual base classes can do it better with
less opportunity for error.  This is not always the case, but in my
experience it sometimes works this way.

3. Overloaded operators.  I don't like this feature at all.  It doesn't
really add overhead, but it's confusing to me.  A lot of people love it
though.  Maybe it's a matter of taste.

Even very good people look at me askance when I say I uses C++ for embedded
applications.  However, it works for me.  I am able to bring projects in on
time and they work correctly.  It's tough times, and I am able to stay very
competitive with embedded C++.

Re: C++ in embedded systems
Quoted text here. Click to load it

You seem to be the exception to the rule.  As many others have said, C++ is
a large language, and thus, hard to learn all of it.  You don't seem to
have this problem.  Clearly, different people have different capacity to
effectively use C++.  But after reading 80 or so responses, I've concluded
that there are quite a few misconceptions about C and C++.  This is not
surprising considering this is comp.arch.embedded.  Because I assume most
respondants have a hardware background and moved into software.  You, on the
other hand, probably have a software background and moved into hardware.
This is certainly the case for me.

Because of my background, I would like to clear up some of the misconceptions.
The biggest misconception I've seen is the concept of object oriented
programming.  I get the feeling that not many people realize that C++ is
a multi-paradigm programming language.  There are many programming paradigms.
http://www.wikipedia.org/wiki/Programming_paradigm contains a list of them.
One important one not covered in this site is the generic programming

C++ supports three different programming paradigms; procedural, object
oriented and generic.  Procedural programming is supported through the
backward compatibility with C.  Object oriented programming is supported
through the classes and all of the features associated with them.  Generic
programming is supported through templates.  With three supported paradigms
is it any wonder that the language is large?  But this doesn't necessarily
mean the language is hard to learn.  Which is a subjective evaluation in
any case.  I.e. learning music is hard for me, but that doesn't mean sheet
music should be thrown out.

Once you understand that C++ supports multiple programming paradigms,
the other misconceptions become obvious.

1.  C++ is hard to learn.
    This is only the case if you are trying to use all three paradigms
    at once.  There's no requirement for this.  It also explains why
    the C++ standard is multiple times larger than other languages.
    Name me another language that supports multiple paradigms and
    then we can compare.

    I should also note that much of the C++ language standard text
    covers the standard library.  Which is an order of magnitude larger
    than most other languages.  The C++ language proper is mostly
    equivalent in size to other languages if you only compare the
    paradigms individually.

2.  C can simulate features of C++ (encapsulation, inheritance, etc).
    Any language can simulate most other languages.  But this doesn't
    mean you are shifting paradigms.  People assume that just because
    they use encapsulation (abstract data types), that they are doing
    object oriented programming.  This is a major misconception.
    Object oriented programming is not just about encapsulation and
    inheritance.  It is a methodology, a paramdigm shift.  Object
    oriented programming is a way of looking at the problem, and a
    way of looking at the solution to this problem.  This is explained
    in the URL link above.

    For those who have ported your C software to C++ and declare you're
    doing object oriented programming, ask yourself this question:
    did I perform a paradigm shift?  If the answer is no, then you
    aren't doing object orient programming.

3.  Rudimentary inheritance can be achieved with nested structures in C.
    This is a mistake people often make with object oriented programming.  
    First of all, nested structures in C is equivalent to C++ data
    composition.  This is not inheritance.  Second, inheritance involves
    more than just inheriting data variables, it also involves inheriting
    interfaces.  You can't do this in C.  When people talk about C++
    inheritance, they are often talking about the latter.

4.  C++ is bloated (binary wise)
    Whether your resulting binary is bloated or not is an implementation
    issue, not a language issue.  You can easily bloat any binary using
    any language.  For example, if I did a copy and paste of a block of
    code in C, then I've just bloated my final executable.  The difference
    between this and inline functions, and templates in C++, is that
    it is a lot easier to make this mistake in C++.  But this IS a
    mistake by the programmer, and not a inherent problem in the C++
    language.  You can't fault a language because there are a lot of
    poor C++ programmers.

    Of course, one could say that it is these faults in C++ that are
    producing so many poor programmers.  True, a good language should
    make it possible to use it effectively.  But ultimately, this is
    a catch 22.  Are the faults creating poor programmers, or are poor
    programmers faulting sound features of C++?  I guess it depends on
    who you ask.

5.  C++ is slow (compile and execution)
    For compilation, this is a problem with the tools, not the language.
    Though the language makes it harder for the tools.  As for execution,
    this is the same as #4 above.  Don't blame the language for the
    programmer's limited abilities.

    But note, even though most of the slow down is due to poor programming.
    There are inherent performance problems in C++, simply due to the
    object oriented paradigm.  The explanation for this is that, any
    performance lost, you gain in ease of maintenance, and you can
    always use a more powerful processor.

    I personally disagree with this line of thought.  As any embedded
    system engineer knows, you don't always have the extra 100 watt
    power supply for the Pentium4, or the extra 5cm square of real-
    estate for the fan.  Simply asking for a bigger processor is not a
    solution to a performance problem in an embedded system.

    Of course, the only thing this means, to us embedded software
    engineers, is that we can't use C++ in all applications.  I.e. I
    wouldn't use C++ in a Microchip PIC solution, even if I could find
    a compiler.  I believe someone else already said the same thing.
    I don't see how anyone could find this as any surprise.  But given
    a 32bit processor, are there any doubt that C++ can provide some
    benefit?  Even if you're only using the procedural programming

There is also the issue of whether to use object oriented programming vs.
procedural programming.  But this is a separate debate, because there are
other languages besides C and C++ that supports these paradigms.  So I'll
leave that debate for another day.  ;-)

Jimen Ching (WH6BRR)       snipped-for-privacy@flex.com     snipped-for-privacy@uhm.ampr.org

Site Timeline