In article <11*********************@g47g2000cwa.googlegroups. com>,
James <si******@gmail.com> wrote:
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.
--
Feep if you love VT-52's.
