Coding embedded systems with C

[James]

I heard C is better for programming embedded systems than C++? Is this
true, if so why?

 

[Emmanuel Delahaye]

James wrote on 26/07/05 :

I heard C is better for programming embedded systems than C++? Is this
true, if so why?

The fact is that sometimes, there is no choice. The only compiler
available for a given platform is a C-compiler. Period.

That said, if there was a choice, both of these languages could fit.


--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"Clearly your code does not meet the original spec."
"You are sentenced to 30 lashes with a wet noodle."
-- Jerry Coffin in a.l.c.c++

 

[Walter Roberson]

I heard C is better for programming embedded systems than C++? Is this
true, if so why?

It depends. C tends to be more conservative in its use of
memory. There are fair number of meaningful C programs that can be
written without using dynamic memory allocation (e.g., malloc).
When you get to C++ you have to be fairly careful to use
only static objects (whose memory can be allocated at compile time,
in theory) instead of the normal dynamic objects (which tend
to use dynamic memory behind the scenes.)

Also, when creating a C++ object, the work that will be involved
in running the constructors is less easily analyzable, unless
one takes care to use simplified objects and is relatively rigerous
in how one invokes the constructors. One can certainly do such things
in C++, but C++'s OOP (Object Oriented Programming) is based around
the idea that one shouldn't worry overly much about glue code and
glue objects, that one should write natural and reusable code and
let the compiler take care of conversion details.

Then there is the factor that the mandatory C++ library is *much*
bigger and more complex than the mandatory C library. Certainly
a good linker would not link in library code that wasn't needed,
but with the emphasis on templating and object reuse, the -tendancy-
in the C++ library is for high level interfaces to end up invoking
a wide variety of lower level interfaces, whereas in C there is
more of a -tendancy- to write just what is needed for the higher
level interface at hand. Of course, -tendancies- are not "proof",
so Your Milage May Vary.

With any given C++ implementation, one thing I would wonder about
is whether, when a particular object constructor is used, all the
code for the other constructors for that object type are also pulled
in -- or whether the implementation is thorough enough to do a
complete enough transitive linking to be able to prune out unused
constructor code. That would be a Quality of Implementation issue,
and could vary between releases -- and where it was present,
minor code changes could result in fairly large differences in
the code footprint.


These having been said, I'm sure there are also benefits for
using C++ in some embedded environments -- for example, when
one is writing a controller for a nuclear reactor, one would
prefer to -know- that string overflows are not possible because
one has consistantly used a length-checking "string" class instead
of char[] arrays that require more programmer effort.

 

[Alexei A. Frounze]

James wrote on 26/07/05 :

The fact is that sometimes, there is no choice. The only compiler
available for a given platform is a C-compiler. Period.

That said, if there was a choice, both of these languages could fit.

C++ can be quite an overhead if used at full (inheritance with vtables,
worse if long chain of descendents; memory allocation here and there if you
create objects, etc). Actually, albeit different from what you want, this
article can be helpful to see more on C++ specifics for coding kernel,
drivers and other low level system things:
"C++ for Kernel Mode Drivers: Pros and Cons" may be useful:
<http://www.microsoft.com/whdc/driver/kernel/KMcode.mspx>

HTH
Alex

 

[Fao, Sean]

I heard C is better for programming embedded systems than C++? Is this
true, if so why?

In addition to what the others have said, I must argue that many (myself
included) still find it necessary to compile their code into Assembly.
That being said, I find it *much* easier to follow C code that's been
compiled into Assembly. I went nutty trying to follow what my C++
compiler optimizer had done with my C++ code. The Assembly output from
my C code, on the other hand, is commonly nearly identical to the C
code. That's reason enough for me ;-).

 

[Hans]

I heard C is better for programming embedded systems than C++? Is this
true, if so why?

That kind of depends on what you mean by "embedded".

Are you short on ROM/RAM - such as having to fit in to a 64kB address
space? Then some C++ features will be unavailable. You can probably
forget about RTTI, exceptions and STL. Dynamic memory will be a very
tight squeeze to fit in. Much of C++ will work, though. I built a
simple RTOS in C++ a while back; on a Renesas H8, the kernel and two
empty tasks weighed in at 5kB of code. Turning on exceptions swelled
the code to 300kB, due to the mass of library functions that were
linked in.

However, a cellphone with memory sizes in the 16MB range is still an
embedded system - and there all the above features can be included.

Do you have special realtime requirements, such as having to meet a
hard deadline? Many people will tell you to be wary of exceptions in
such circumstances, since the timing of stack unwinding can be hard to
predict - at least in the parts of your code that needs to meet those
deadlines; in my experience, only a very small part of the code in a
realtime system is subject to the realtime constraints.

Anyway, the bottom line is that C++ can be considered a superset of C.
For any given project, examine your constraints. Use the extra C++
features that fit within those constraints, be they memory or timing
related. Skip the C++ features that don't fit.