Exploring C11/C18 and C++14/C++17
IAR Embedded Workbench delivers support for the latest C11/C18 and C++14/C++17 language standards. But how to make use of these standards? Explore its capabilities in this article.
The C language standard ISO/IEC 9899:2012 and C++ standard ISO/IEC 14882:2015 or just better C11 and C++14 have been around for a while. Support for these standards is available in mainly all recent IAR Embedded Workbench releases.
C++ has influences from lot of other languages. Started as a project to improve C in 1979 and was named C with classes and finally changed name to C++ in 1983. The first commercial release was in 1985.
The short story is that C++14 is ”based” on C11 that attempts to fix what was broken in C99. C11 is a superset of C99 and is more compatible with C++. This makes the mix of C and C++ easier. In real applications we have the semiconductor vendors providing their low level drivers in C. If you want to develop your embedded application in C++ you end up in doing a mix from the libraries provided in C and your application written in C++. This use case of mixing C and C++ is very well supported by IAR Embedded Workbench. The Auto (extensions-based) language selection is recommended in this case.
The C++ options "Enable exceptions" and "Enable RTTI" might not be available IAR Embedded Workbench architectures.
So what’s new?
I will not go through all features in detail but I thought I would list some of them. C18 and C++17 mainly focused in fixed issues in C11 and C++14. This article will mainly explore the new features introduced by C11 and C++14.
C11
- Type-Generic Functions
- Memory Alignment Control
- The _Noreturn Function Specifier
- Unicode Support
- Static Assertions
- gets() Removed
- Macros
- complex values
- subnormal floating point numbers
- and much more
C++14
- Automatic type inference
- New binary constants
- The [[deprecated]] and[[noreturn] Attributes
- Generic Lambdas
And also:
- Move semantics
- Range based for-loops
- New string literals for Unicode encoded strings
- Atomics
- Null pointer constant
- Lots of other smaller features
How is my current project affected?
Porting your C or C++ application should be pretty straightforward. The most dramatic change is that the Embedded C++ and Extended Embedded C++ language and library mode is no longer supported. This is due to the obvious reason that the own subset of C++ can be defined by the end user and extended to the full C++.
When porting an Embedded C++ application it can be a major issue that the C++ library symbols now reside in the std namespace. The user must then either prepend each reference to such symbols with std:: or must insert the following line after the include directives but before any C++ library symbol references, in each C++ source file or suitable header file(s):
using namespace std;
Also, a side effect of dropping support for the old Extended Embedded C++ STL is that STL can only reside in the default memory and operate on default pointers. For more information, have a look in the C/C++ Development Guides, chapter “Porting code from EC++ or EEC++" in the user guides.
Switching to the new standards
When you switch to C11/C18 and C++14/C++17 you will have access to a safer standard and get access to the performance benefits for free, for example the move semantics that will reuse and optimize the way of copying, aside of auto, atomic and so one. All the new features will also help you to be more productive and have smaller and more readable code.