C++ usage in embedded systems

Question

What features of C++ should be avoided in embedded systems?

Please classify the answer by reason such as:

• memory usage
• code size
• speed<

Answer 1

Note that the cost of exceptions depends on your code. In one application I profiled (a relatively small one on ARM968), exception support added 2 % to execution time, and code size was increased by 9.5 KB. In this application, exceptions were thrown only in case something seriously bad happened -- i.e. never in practice -- which kept the execution time overhead very low.

Answer 2

It's an interesting read for the Rationale on the early Embedded C++ standrard

See this article on EC++ as well.

The Embedded C++ std was a proper subset of C++, i.e. it has no additions. The following language features were removed:

• Multiple inheritance
• Virtual base classes
• Run-time type information (typeid)
• New style casts (static_cast, dynamic_cast, reinterpret_cast and const_cast)
• The mutable type qualifier
• Namespaces
• Exceptions
• Templates

It's noted on the wiki page that Bjarne Stroustrup says (of the EC++ std), "To the best of my knowledge EC++ is dead (2004), and if it isn't it ought to be." Stroustrup goes on to recommend the document referenced by Prakash's answer.

Answer 3

If you're using an ARM7TDMI, avoid unaligned memory accesses at all costs.

The basic ARM7TDMI core does not have alignment checking, and will return rotated data when you do an unaligned read. Some implementations have additional circuitry for raising an ABORT exception, but if you don't have one of those implementations, finding bugs due to unaligned accesses is very painful.

Example:

const char x[] = "ARM7TDMI";
unsigned int y = *reinterpret_cast<const unsigned int*>(&x[3]);
printf("%c%c%c%c\n", y, y>>8, y>>16, y>>24);

• On an x86/x64 CPU, this prints "7TDM".
• On a SPARC CPU, this dumps core with a bus error.
• On an ARM7TDMI CPU, this might print something like "7ARM" or "ITDM", assuming that the variable "x" is aligned on a 32-bit boundary (which depends on where "x" is located and what compiler options are in use, etc.) and you are using little-endian mode. It's undefined behavior, but it's pretty much guaranteed not to work the way you want.

Answer 4

Choosing to avoid certain features should always be driven by quantitative analysis of the behavior of your software, on your hardware, with your chosen toolchain, under the constraints your domain entails. There are a lot of conventional wisdom "don'ts" in C++ development which are based on superstition and ancient history rather than hard data. Unfortunately, this often results in a lot of extra workaround code being written to avoid using features that someone, somewhere, had a problem with once upon a time.

Answer 5

Exceptions are likely going to be the most common answer of what to avoid. Most implementations have a fairly large static memory cost, or a runtime memory cost. They also tend to make realtime guarantees harder.

Look here for a pretty good example of a coding standard written for embedded c++.

Answer 6

Make sure you know what features are supported by the compiler for your embedded platform and also make sure you know the peculiarities of your platform. For example the TI's CodeComposer compiler does not do automatic template instantiations. As a result, if you want to use STL's sort, you need to instantiate five different things manually. It also does not support streams.

Another example is that you may be using a DSP chip, which does not have hardware support for floating point operations. That means every time you use a float or a double you pay the cost of a function call.

To summarize, know everything there is to know about your embedded platform and your compiler, and then you will know which features to avoid.