The Irrelevance of the New C++ Standard
Written by Darren R. Starr   
Tuesday, 12 July 2011

Does C++ benefit from standards if they take years to complete and only get patchy practical support?


The latest C++ standard was recently ratified. Those guys did a great job of making yet another C++ standard that will still not be implemented by anyone even 10 years later. Languages developed by ISO standards committees border on being a waste of time. The progress of programming language development moves far too fast to be stuck in committees for years.

C++ is a great language fundamentally, but it becomes truly powerful when it is portable. The previous C++ standard published in 2003 still isn't completely implemented on most systems. Additionally, even with all the nifty work done by the ISO committees, the libraries are still thoroughly incomplete and the documentation for the libraries is generally poor at best.

The C++ standards committee these days is little more than a group of people who spend months or years bickering over what new features get into the standard or not. In the end, they produce what they refer to as a standard, but without a reference implementation and therefore its value is as little more than a list of suggestions for features.

There are many different types of C++ developers. But the groups which are most noticeable are :

  • Use the language, write the libraries from scratch
  • Use the language and the libraries and change jobs if you can't
  • Use the language and use someone else's libraries

I have worked on some fairly major software products over the years. In nearly all those cases, the companies I've worked for belonged to either the first or the last of these categories. Standard C++ libraries have never been an option for us. We develop for too many platforms and frankly, the C++ standard was never standard enough to work on all the platforms we worked on. Therefore, we would develop libraries which would make use of the lowest common denominator between compiler capabilities and develop our own C++ libraries for nearly everything. I know I've helped reinvent the wheel several times over.

The latest generation of the C++ standard contains a huge number of great, lovely, mouth watering features. There are lambda functions, a truly glorious extension to C++. My favorite extension to C++ by leaps and bounds above all others has to be In-class member initializers which hasn't even been implemented in Intel C++, GCC, EDG or LLVM at the time of this writing.

Before I can start using any of these features, I need to make sure that all the compilers and platforms I work on will support these new features. Maybe within two or three years, I'll feel safe with some of the more trivial changes, but for items such as lambdas, I don't expect to be able to use for another decade.

There is no actual standard C++ library either. Instead, developers are left to choose between which implementation, or interpretation of the specification you feel most comfortable with. There are several to choose from [5] :

- - The highly restrictive GNU Standard C++ Library

- - The extremely expensive Dinkumware and Roguewave implementations

- - The extremely Microsoft implementation

- - The extremely dated and incomplete STLport implementation.

In short, instead of a shipping a completed Standard C++ Library from a controlled environment with a porting layer for platform vendors, instead a specification which must be read and interpreted must be shipped. This is unforgivable.

Lack of Unicode support [6]. Still to this day. Years after C++ became popular, we're still forced to implement our own unicode handling. Of course, for the most part, the new specification adds a few string literal handlers to make life easier, it's still a nightmare to cope with foreign languages in your programs.

Lack of support for users. Come on already guys. Why are you bothering to write a set of libraries which are already duplicated in every windowing toolkit out there? It just adds further confusion to the language. We're forced to implement converters every time we need to us the Standard C++ library strings. Standard C++ Library collections are even more problematic.

New language features are often very welcome. I'm excited about all the goodies I'll have access to in 2021 thanks to this spec. But this is the real world.

I'll stick to Qt for as long as I can. Qt provides a standard set of C++ libraries are that are uniform and consistent across all the platforms which it runs on. Porting the core libraries of Qt to a new platform can be done in hours by an amateur. On desktop (Windows, Mac and Linux) and mobile phone platforms (Android and iPhone) I have the ability to write entire user interfaces in a variety of ways. My code can then be ported from platform to platform relatively easily. Using Qt language extensions, I can release internationalized code which is uniform across all platforms. In the old days, when GCC had miserable support for templates, Qt even shipped with collections optimized for templates on Visual C++ and for macros on GCC.

The relevance of the new C++ spec is highly questionable. We love new features in our languages, but when the C++ committee spends years adding new features we've pretty much all worked around in the past and extends the language so greatly that it'll most likely never become universally standard, it becomes time to stop bothering with the standard.

It's about time the C++ standards committee starts focusing on making the standard happen. That includes producing a reference implementation (or at least parser and verification code generator). It includes dropping all support for standard C++ libraries. They are just older versions of what's part of boost anyway.

More Information

Non-static data member initializers.
Lambda expressions and closures for C++

Lambda Expressions and Closures: Wording for Monomorphic Lambdas

New wording for C++0x Lambdas.
Wide character

Standard library

Last Updated ( Friday, 24 October 2014 )