{"id":8048,"date":"2025-11-29T09:19:11","date_gmt":"2025-11-29T08:19:11","guid":{"rendered":"https:\/\/web-dev-weissblau.de\/microconsult\/?p=8048"},"modified":"2026-02-11T06:24:45","modified_gmt":"2026-02-11T05:24:45","slug":"who-is-afraid-of-evil","status":"publish","type":"post","link":"https:\/\/www.microconsult.de\/en\/wer-hat-angst-vorm-boesen\/","title":{"rendered":"Who's afraid of the evil "++"?"},"content":{"rendered":"

Why C++ makes sense down to the driver level<\/h2>\n

Author: Matthias Bauer, redlogix Software & System Engineering GmbH<\/p>\n

Contribution \u2013 Embedded Software Engineering Congress 2015<\/h3>\n

Some prejudices are incredibly persistent. For example, this one: C++ is unsuitable for extremely resource-poor systems. This is simply not true! On the contrary, using the right C++ language features offers invaluable advantages, especially for systems with extremely limited resources.<\/strong><\/p>\n

By using the compiler as a code generator, programs can be created from generic, flexibly configurable software components, without any runtime overhead compared to a custom solution. This is particularly interesting for applications that are integrated on platforms with very limited resources (e.g., code storage, RAM, processing speed, energy).<\/p>\n

Does "++" indicate a greater need for resources?<\/h2>\n

At a very superficial glance, one might actually conclude that software developed in C++ generates larger binary code than its counterpart in C.<\/p>\n

For example, if you build a simple Hello World program in C and C++ using the Keil uVision development environment for a Cortex-M3 target, C++ skeptics will initially feel vindicated: While the program written in C occupies code memory in the low single-digit kilobyte range, the C++ program occupies more than 30 kBytes (see Figures 1 & 2).,\u00a0PDF<\/a>).<\/p>\n

However, the increased code memory consumption is not due to the C++ programming language itself. Using certain parts of the Standard Template Library introduces library code that is not optimized for embedded applications and, in some cases, utilizes C++ features that are better left out in applications with extremely limited resources (e.g., exception handling).<\/p>\n

Therefore, caution is advised when using the STL on embedded targets for several reasons. For example, the collection classes use dynamic memory allocation by default, which sooner or later leads to memory fragmentation problems on systems without virtual memory management.<\/p>\n

The C++ programming language itself can be used without hesitation, without tying up more valuable system resources than C. With C++, you only pay for the features you actually use, using the currency of "resources." Of course, you should know exactly which language features might incur additional resource costs.<\/p>\n

Overview of resource costs of some C++ language features<\/h2>\n\n\n\n\n\n\n\n\n\n
Language feature<\/strong><\/td>\nResource costs<\/strong><\/td>\nRecommended use (*)<\/strong><\/td>\n<\/tr>\n
Classes without virtual methods<\/td>\nNo additional resource requirements compared to normal C functions that work on data structures.<\/td>\nwithout restriction<\/td>\n<\/tr>\n
Inheritance<\/td>\nNo additional resources are required. A class that inherits members from base classes does not require more code or data storage than if it had defined all members itself.<\/td>\nwithout restriction<\/td>\n<\/tr>\n
Use of access protection for class members (private, protected, public)<\/td>\nNo additional resources are required, as the check takes place exclusively at compile time. The concept of inline functions also eliminates the costs associated with public getter and setter methods for accessing protected member variables.<\/td>\nwithout restriction<\/td>\n<\/tr>\n
Virtual methods<\/td>\nTypically (depending on the compiler), additional code memory is required for method jump tables and data memory for managing a pointer to them.
\nIf one wanted to recreate virtual methods in C \u201eby hand\u201c, it would incur at least equally high resource costs.<\/td>\n		with care<\/td>\n<\/tr>\n
Exceptions<\/td>\nCode storage and data storage (implementation varies significantly in efficiency from compiler to compiler)<\/td>\nIt's best not to use it<\/td>\n<\/tr>\n
Using templates<\/td>\nThey are fully evaluated at compile time, therefore no additional resources are required.<\/p>\n

However, their careless use can lead to a significant increase in the need for code storage.<\/td>\n

with care<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

 <\/p>\n

Templates, in particular, make the C++ language extremely interesting for embedded applications. They allow the C++ compiler to be used as a code generator, producing highly efficient code at compile time from generic and therefore flexibly deployable software components. The concept of code generation can even be used effectively down to the driver level. To illustrate this, let's consider a driver for digital inputs that, for example, should call an application function from the interrupt context on every rising pulse edge.<\/p>\n

The ISR routine of such a driver typically consists of two parts:<\/p>\n

    \n
  1. A hardware-dependent part checks whether the interrupt was triggered by the relevant hardware component (in our case, the input pin) (if multiple sources can trigger the interrupt) and resets the interrupt if necessary.<\/li>\n
  2. Calling a callback routine that is not part of the driver but contains application-specific functionality (see Figure 3,\u00a0PDF<\/a>).<\/li>\n<\/ol>\n

    Case study: A driver with ISR in C<\/h2>\n

    The ISRs of drivers implemented in C typically call the application-specific callbacks via function pointers. The relevant code snippets of such a driver then look like this (see Figure 4).,\u00a0PDF<\/a>).<\/p>\n

    With this approach, the callback routine only needs to be communicated to the driver at runtime, which often allows for unnecessary flexibility. In most cases, the callback routine that the driver should call is already determined at compile time.<\/p>\n

    The same driver with C++<\/h2>\n

    If the driver is implemented using the C++ programming language, arbitrary callback functions can be included in the driver without any function pointers. This is achieved using C++ templates and the concept of template specialization. A driver implemented in C++ can therefore look like this (see Figure 5).,\u00a0PDF<\/a>).<\/p>\n

    Where the driver wants to execute a callback, it simply calls the static method `invokeCallback()` of the class template `TDriverIsrCallback`. By specializing the class template `TDriverIsrCallback`, it is possible to define for each driver what should happen in this static method, i.e., to call the desired application-specific callback routine from there (see Figure 6).,\u00a0PDF<\/a>).<\/p>\n

    When the compiler parses the driver class code, the specialization does not yet need to be available to it. Therefore, the specialization can be implemented outside the driver code module, ensuring the driver remains generic and independent of the application code. The code module with the template specialization shown serves as the link between the application modules and the drivers.<\/p>\n

    Since the compiler optimizes away the invokeCallback() call as an inline method, binary code is generated after code generation as if the callback routine had been called directly in the driver, as shown here (see Figure 7).,\u00a0PDF<\/a>).<\/p>\n

    This technique offers the following advantages over the callback solution using function pointers:<\/p>\n