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 :
In short:-
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.
- Navigating Memory in C++: A Guide to Using std::uintptr_t for Address Handling - February 22, 2024
- Embedded Expertise: Beyond Fixed-Size Integers; Exploring Fast and Least Types - January 15, 2024
- Disassembling a Cortex-M raw binary file with Ghidra - December 20, 2022
Co-Founder and Director of Feabhas since 1995.
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.
There's a new version of the MISRA C Guidelines in the pipeline that caters for both C90 and C99.
I believe that the general reason for the slow uptake in C99 has been for "chicken and egg" reasons; embedded developers weren't asking for C99 features because they weren't aware of them and (embedded) compiler developers weren't implementing new (C99) compiler features because developers weren't asking for them.
I would hope that genuinely useful features to embedded developers such as atomics and thread local storage, etc., would drive demand for compilers compliant with the latest standard.
Pingback: Weekly Roundup for C++, Dec. 5, 2010 « C++ Soup!