The last few years have been dominated by the development of the new C++ standard (still generally referred too as C++0x but now expected in 2011). This will be the second edition of the C++ standard (ISO/IEC 14882) ignoring any TC’s and alike (useful C++0x FAQ here).
However, in parallel and generally under the radar, there has recently been publish a committee draft for the third edition of the C standard (ISO/IEC 9899). This should not really be a surprise, as my understanding is that all standards must be revised or retired every ten years (or thereabouts). But I still find that in the embedded community many people are unaware of the second edition (usually called C99, with the first edition being C90). The support for C99 features has been slow in coming; for example the release notes of the for recently released IAR v6.10 states:
The product now uses the current C standard defined in 1999, known as C99, as the default C language
It is also noteworthy the MISRA_C:2004 still uses C90 (okay C96 if you want to be pedantic) as it’s Rule 1.1 requirement.
So why hasn’t C99 been widely adopted? When asking the question of a someone I know very well, who has been involved in various commitees over the years, I thought I’d share his response :
C90 was needed and it harmonised current compiler practice.
C99 then added a “wish list” of Good Ideas ™ that some people wanted because they were cool. (the ideas not the people 🙂 However the industry in general did not want the new features, many of which had not been thought through as regards implementation. So the compiler companies did not bother. Only adding things when enough people wanted them. E.g. // for comments.
C1* (formerly C0*) is more of the same. People adding Cool features that the industry is not crying out for and compiler vendors have not added. Though some “Cool Ideas” ™ have already been dropped. Fortunately.
I haven’t yet had time to trawl through the standard, but a couple of key changes that sprung out straight away are:
- support for multiple threads of execution including an improved memory sequencing model, atomic objects, and thread-local storage
- static assertions
- support for bounds-checking interfaces (optional)
Once I’ve had opportunity to investigate these further I shall report back.
Niall has been designing and programming embedded systems for over 30 years. He has worked in different sectors, including aerospace, telecomms, government and banking.
His current interest lie in IoT Security and Agile for Embedded Systems.
Latest posts by Niall Cooling (see all)
- Updated: Developing a Generic Hard Fault handler for ARM Cortex-M3/Cortex-M4 using GCC - September 21, 2018
- Code Quality – Cyclomatic Complexity - July 27, 2018
- Bugs do matter…(unsurprisingly) - January 18, 2018