1
\$\begingroup\$

Some features of C++ have implied run-time cost or can lead to significant code size increases. Which features should I consider avoiding when developing for a bare-metal resource constrained microcontroller? And why?

\$\endgroup\$
  • 1
    \$\begingroup\$ Without far more details, this is impossible to answer. n \$\endgroup\$ – Peter Smith May 21 '16 at 15:52
  • \$\begingroup\$ You should avoid anything for which you cannot picture the general shape of the resulting machine-language implementation or be familiar with its size and failure modes. \$\endgroup\$ – Chris Stratton May 21 '16 at 15:58
  • 3
    \$\begingroup\$ Generally the big one is dynamic memory allocation \$\endgroup\$ – DarthRubik May 21 '16 at 16:38
  • \$\begingroup\$ It really depends on your specific system,and if it has constraints like reliability or strict deadlines. \$\endgroup\$ – Sean Houlihane May 21 '16 at 19:35
  • 6
    \$\begingroup\$ electronics.stackexchange.com/questions/3027/… \$\endgroup\$ – Matt Young May 21 '16 at 20:09
4
\$\begingroup\$

Look at the MISRA (Motor Industry Software Reliability Association) guidelines for safe C. They were designed specifically for coding in C and C++ for embedded application.

Wikipedia: https://en.wikipedia.org/wiki/MISRA_C

And the MISRA-C home page: http://www.misra-c.com/

\$\endgroup\$
  • 3
    \$\begingroup\$ There's now a specific MISRA C++ standard as well. \$\endgroup\$ – Simon B May 21 '16 at 21:25
0
\$\begingroup\$

This is a loaded question because avoiding a language feature can lead you to compensate for it. For instance, if you avoid using C++ classes because "vtables" take up space, but then implement your own OOP using C approaches which involve static structures containing function pointers, you've brought back vtables.

Some features can have overhead even if you don't use them, like RTTI (run time type info) and exception handling. Your compiler may have a way to turn these off.

Not using the C++ standard library and especially templates (STL) is another way to save space, provided you don't supplant these with something else that is bloated, and you actually have a way to remove the library (not have it on the target).

Be careful with how you use templates. Whenever possible, design template classes so that they are very light-weight inline functions, using an implementation that isn't a template (and so isn't expanded multiple times).

A generic container or what have you can use void * type approaches and be wrapped by a thin template that provides the type safety. Most of the functions in the wrapper are inlines that perform casting that disappears in the code.

\$\endgroup\$
-2
\$\begingroup\$

I think the language committee did actually take an official stance regarding subsets once -- it was strongly against them.

Other experts feel that there is some value to defining a subset for resource-constrained environments, but the subset language calling itself "Embedded C++" is useless.

The only provision that the official language makes for embedded use is the "hosted"-vs-"freestanding" implementation rules, which allow an embedded system to not support a "main()" function and its associated processing of command-line arguments.

\$\endgroup\$
-3
\$\begingroup\$

C++ usage in most embedded systems designs of the past was to be avoided. In particular, the parts of C++ that create classes and using inheritance, operator and method overloading and use of lots of complex pointer structures for accessing data and/or code. There are two reasons for this, one being the typically limited RAM available in embedded microcontrollers. The second issue is one of basic raw performance if the CPU is handling the advanced features of C++.

There are still plenty of embedded applications, even today, that use the cheaper variety of microcontrollers where the same is true. The trend in the recent decades to have microcontrollers with all their FLASH (ROM) and RAM on board a single chip strengthens this argument even more.

In these more modern times there are now many embedded solutions that are using quite high performance processors that are SOC type components. These often support connection of large amounts of high bandwidth DDR dynamic RAM type memory for program execution and data store. These parts also support high density serial FLASH parts for loading the program code into the DDR RAM for execution even including an operating system like an embedded Linux or RTOS. These embedded systems have performance and memory resources that rival the typical PC performance of former times. Usage of C++ features in such a system is certainly feasible. That said there is a whole separate subject of embedded system predictable performance and reliability that comes into play where the complexity of an embedded Linux and/or the overloaded data structures of a C++ implementation come into question and in many instances are to be avoided.

\$\endgroup\$
  • 4
    \$\begingroup\$ Overloading costs nothing compared to giving the same functions different names. You're spreading misinformation about many other features as well. There are parts of C++ that don't play well with resource-constrained systems, but none of the ones you mentioned are among them. \$\endgroup\$ – Ben Voigt May 21 '16 at 22:01
  • 1
    \$\begingroup\$ @ChrisStratton: But none of those are contained in C++, and it's just as easy to design complex pointer structures for accessing data and code in C as it is in C++. If you look at any C++ feature that does add indirection (such as a virtual function call), you find that the C++ implementation is typically the leanest of the possible ways of accomplishing it. \$\endgroup\$ – Ben Voigt May 21 '16 at 22:16
  • 3
    \$\begingroup\$ One can certainly implement object paradigms in C with structures of data and function pointers, but it's painful enough that you realize the implementation cost of doing it, and pause to contemplate if it's truly appropriate for your goals. With C++ it's just what people habitually do, and that lack of thinking is where the embedded systems risk comes in. \$\endgroup\$ – Chris Stratton May 21 '16 at 22:18
  • 1
    \$\begingroup\$ @Chris: If you just use the C++ features this answer rails against, you won't get any. Other C++ features may give you one layer of pointers. You never end up with "complex pointer structures" unless your code explicitly creates that complexity. The rest of your comment seems to be about good vs bad programmers, and again applies equally to any language. \$\endgroup\$ – Ben Voigt May 21 '16 at 22:25
  • 2
    \$\begingroup\$ @ChrisStratton A virtual function isn't used in vacuo. It typically replaces switch or if statements, and its implementation via vtables is generally a much more compact solution than either. Not an 'efficiency or space loss'. \$\endgroup\$ – user207421 May 22 '16 at 0:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.