cpp_logo.pngAccording to a recent Embedded Systems Survey by the Barr Group, “Nearly 95% of embedded programmers wrote the majority of their code in C or C++”. The popularity of C++ for embedded applications is growing while the language continues to evolve. C++14 is the latest published version of the ISO standard, and C++17 Draft International Standard (DIS) was recently approved. We can now expect C++17 publication before the end of 2017.
What will this mean for embedded systems development?

Historically, the adoption of new languages and standards has been slow. As a young embedded C developer in the early ‘90s I attended a training course, “Object Oriented Programming in C++”. Shortly afterwards I switched jobs and began to develop C++ applications for Windows. Upon joining PRQA and researching the embedded software market some 25 years later I find it noteworthy (though perhaps unsurprising) that C is still the primary language for over 70% of embedded systems!

In the past, a significant barrier to the adoption of a new standard has been the length of time taken for platforms and tools to catch up. This has changed in recent times. According to prominent C++ expert Herb Sutter, “we see at least one major implementation that has all C++17 features in the same year that C++17 is published…all of the major compilers’ current releases are in closer sync with the standard than they’ve ever been before”.

Does the availability of compiler support mean that embedded developers will adopt C++17 straight away? Software developers will need to consider the potential benefits. Typical questions will be:

  • Will it save development time?
  • Will it reduce code maintenance costs?
  • Will it improve runtime performance?
  • Will it reduce safety and security risks?


Full details of the changes between C++14 and C++17 may be found on the ISO C++ website. Some features such as “Selection statements with initializer” and “Structured bindings” can potentially enable neater code and reduce keystrokes for those who develop an understanding of the syntax, but they don’t seem earth-shatteringly significant in terms of development time and cost savings. “Guaranteed copy elision” is designed for improved compiler optimisation and hence may improve runtime performance, but once again does not seem significant in the grand scheme of things. In terms of safety and security, the removal of trigraphs and dynamic exception specifications, and stricter order of expression evaluation are positive moves to prevent unspecified or undefined behaviour. These are already covered by those using QA·C++ for MISRA compliance:

  • Rule 2.3.1 "Trigraphs shall not be used"
  • Rule 5.0.1 “The value of an expression shall be the same under any order of evaluation that the standard permits”
  • Rule 15.4.1 “If a function is declared with an exception-specification, then all declarations of the same function (in other translation units) shall be declared with the same set of type-ids”)


There are also equivalent rules in PRQA’s own High Integrity C++ (HICPP) standard:

  • 2.2.1 Do not use digraphs or trigraphs
  • 5.1.2 Do not rely on the sequence of evaluation within an expression
  • 1.3.5 Do not use throw exception specifications


The introduction of the std::byte type will distinguish byte-oriented access to memory from accessing memory as a character or integral value, which improves type safety. It will also improve readability by making the intent of the code clearer to readers.

Perhaps the standout addition to the C++17 is the introduction of the parallel algorithms library. Multi-processor systems are required for computationally intensive applications and artificial intelligence. The parallel algorithms library will make it easier for programmers optimize the execution of standardized algorithms on this type of system.

Will you adopt C++17? What do you think will be the most valuable features? Please leave your comments below…

 Request the High Integrity C++ overview whitepaper