Post by email@example.com Post by Dombo Post by firstname.lastname@example.org
I think that small micro-controllers, that is computers that
address no more than 64 KB of code, are still used, and that for
that C++ language is not actually used and should not be actually
The Arduino people felt differently; few people realize that the
Sketch programming language used to program a lowly 8-bit Atmel AVR
micro-controller with significantly less memory than 64KB is
actually C++. I wouldn't say that that is the best example of C++
on small micro-controllers, but I see few problems with judicious
use of C++ on those other than that the benefits of C++ may be less
significant for small programs.
According the TIOBE index (
there are more than three times as many C programmers as C++
programmers. What kind of software do they develop, if even lowly
8-bit micro-controllers run C++ software? Here I don't want to speak
about which language is better, but I heard that C++ is much less
used than C (or assembly) language for applications that need to keep
code less than 64 KB. However, as I now see so much interest, I will
try to keep those platforms into account, but without removing the
requirement for some C++11 conformance.
As others have noted, TIOBE is /completely/ pointless as a judge of how
much something is used.
There are massive amounts of C code in common use on all sorts of
platforms, and much of it is under continuous development.
Regarding embedded systems, there is no magical "64KB" boundary as you
seem to think. There is, however, a stronger bias towards C rather than
C++ as systems get smaller. At the bottom end, small microcontrollers
often have very limited cpus - they are barely suitable for C
programming, never mind C++ style programming. Toolchain vendors for
such devices are limited, and their tools are limited - often there
simply are no C++ compilers available.
For bigger processors, C is still the preferred choice for a lot of
embedded programming - and when C++ is used, it is often used in a way
that differs significantly from desktop or "big system" C++ programming.
In particular, in small embedded systems there is an emphasis on code
size (thus one avoids large libraries), static behaviour (heaps, dynamic
memory, virtual functions, etc., are banned or discouraged), clear code
flow (so you avoid exceptions), and code correctness (this also means
knowing all your code, and therefore keeping source sizes to the minimum).
I think, however, there is a trend towards more C++ even in small
systems (just as assembly has been mostly pushed out in favour of C).
Part of this is that "small" microcontrollers have been getting "bigger"
(in particular, Cortex M cores have pushed out a lot of 8-bit cores).
Part of this is that the tools are getting better, and part of it is
that the language is getting better (C++11 has a lot of improvements).
Regarding compatibility of a C++ library with "small embedded C++",
there are a few things to consider:
There should be no use of exceptions or RTTI - these are almost always
disabled on small systems. Some embedded development tools do not have
support for them at all, and even when they are supported they lead to
very significant extra library code, limits on optimisation, extra code
in use, and most importantly, exceptions make it hard to be sure that
everything is correct because they introduce "hidden gotos".
There should be no reliance on the heap. With small systems
programming, you have limited memory, and you need to know that
everything fits - you do not want to leave memory management to
run-time. As much as you possibly can, you want all memory to be
allocated statically so that you can see exactly what is used, and check
it at compile-time. It also means smaller and faster code - on some
processors, several times faster. One "innocent" use of std::vector
rather than std::array can use up half your code flash space and make it
impossible to analyse your memory usage fully.
Virtual functions, and polymorphism in general, should be avoided unless
they really help. Multiple inheritance is right out. In general, you
want the compiler to know as much as possible at compile time. It
doesn't matter if that means re-compiling lots of code in every build -
compile time is cheap, but run time is expensive.