Should I Adopt C++17?
C++17 is the latest version of the C++ programming language.
While C++ is widely used — especially in embedded development — C++17 is not widely adopted.
How Programmers Use Embedded C++
According 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. The most recent version, C++17, was published in late 2017.
Adopting New Programming Languages for Embedded Systems
Historically, the adoption of new languages and standards has been slow.
As a young embedded C developer in the early 1990s, I attended a training course, “Object Oriented Programming in C++”.
Shortly afterwards I switched jobs and began to develop C++ applications for Windows.
Now — 25 years later — I find it noteworthy (though perhaps unsurprising) that C is still the primary language for over 70% of embedded systems!
Adoption of C++ has been slow. And it takes time for new versions of the language to be adopted.
So, Should I Adopt C++17?
In the past, a significant barrier to the adoption of a new language has been the length of time taken for platforms and tools to catch up.
This has changed.
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?
It's possible, but unlikely.
4 Questions to Ask Before Adopting C++17
You'll need to weigh the benefits with potential drawbacks.
Consider the following questions:
- Will it save development time?
- Will it reduce code maintenance costs?
- Will it improve runtime performance?
- Will it reduce safety and security risks?
Pros and Cons of C++17
C++17 includes features that improve your code, performance, and security. While these are nice features, they're not earth-shattering.
One of the biggest additions is the introduction of the parallel algorithms library.
Multi-processor systems are required for computer-intensive programs and artificial intelligence. The parallel algorithms library makes it easier to execute standardized algorithms on this type of system.
There are two features that will enable cleaner code:
- Selection statements with initializer.
- Structured bindings.
This also reduces keystrokes for those who understand the syntax.
So, these features provide a step up for cleaner code.
Interested in writing cleaner code? Get coding best practices for C++ >
“Guaranteed copy elision” is designed for improved compiler optimization. So, it may improve runtime performance.
Safety and Security
C++17 also includes features that improve the safety of your program and ensure secure coding:
- Removal of trigraphs and dynamic exception specifications.
- Stricter order of expression evaluation.
- Introduction of std::byte type.
The first two features prevent unspecified or undefined behavior.
The std::byte feature improves type safety. It distinguishes byte-oriented access to memory from accessing memory as a character or integral value. It also improves readability. The intent of the code is clearer.
Is C++17 Supported by Compliance Standards?
Compliance can be a barrier to C++17 adoption. And in order to adopt a new version of embedded C++, you need to be certain that you can use it and still be compliant. And that means having a coding standard that supports your language.
C++17 and MISRA
Many of the new features in C++17 are already covered by those using Helix QAC for MISRA C++ 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”
C++17 and High Integrity C++
There are also equivalent rules in the High Integrity C++ (HICPP) standard (developed by Perforce static analysis experts):
- 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
Moving to Modern C++
Interested in moving to modern C++? Learn how to do it.