C++ Status

published at 27.03.2014 16:30 by Jens Weller
Save to Instapaper Pocket

So, for one year I've been reading Proposals for the C++ Committee, some thoughts on where its going, and where its currently at. And now that C++14 is in its final draft state, also a look into the Standards beyond C++14.

This is the followup I promised after my last series for Issaquah. The current status of the standardization is that C++14 is on its final way to become a new ISO Standard, as you can see on the C++ Status Page of isocpp.org. The very informative status image shows you the past and future of C++ Standardization:

It very nicely shows the gap between '03 and '11 in Standardization of C++, and how things have changed now, C++ is now a language with a constantly active Standardization Committee. C++ will keep evolving, and have new interesting features such as Concepts (lite) and modules in the (far?) future. What this image also shows, is the recent trend to a more formalized Standardization: Proposals -> Technical Specification -> ISO C++ Standard. This will allow for a better adoption to the standard by the compiler vendors, as they likely will already have a TS Implementation. This is especially interesting for library features, as they do not require changes in the language. So, in 2014 this image promises us the technical specifications for:

• filesystem
• library fundamentals
• networking
• concepts (lite)
• array extensions

Followed by parallelism, concurrency and transactional memory. All of this could make it into C++17 when its published as a TS by 2015. But keep in mind that prediction is very difficult, especially about the future (Niels Bohr).

C++17 or maybe C++1y

What actually surprised me in the above image, that the committee really seems to aim for shipping in 2017. IMHO for a major standard that is 2 more years of work and one year of polishing. I like the idea of shipping every ~5 years a new major version of C++, and maybe in between a minor version to fix bugs and update the language. For me the three most interesting features that can be expected in C++17 are concepts, parallelism/concurrency and reflection. Maybe there will also be support for modules, but I doubt that currently.

Concepts lite

Concepts got removed from C++11, and the currently favored approach to Concepts is mostly known as Concepts lite. Which is a first step stone to a fully functional version of Concepts in the language. Already concepts lite will have a huge impact on the language, as this will also require to implement a Concepts Standard Library. Which could lead to a major rewrite or refactoring of the C++ Standard Library in order to support concepts. But C++17 might first bring only the language support, with later adding Library support for Concepts. As C++ is a multi vendor language, this might also differ from compiler to compiler. As we've seen the speed of C++11/14 adoption differ widely in the last years.

Parallelism & Concurrency

The most interesting part for me is resumable functions, which would make it easier to write parallel code in C++. But also this would improve the support for threading, and having a threadpool in the standard library would really help. The with C++11 added threading features would be improved largely by making task based concurrency available to Standard C++.

Reflection

Just until a few weeks I thought that reflection support in C++ would be as far away as modules. Simply because I didn't see many interesting proposals for it while reading the papers for the C++ Committee meetings. This changed with the mailing after Issaquah, there is a very good and detailed paper now available: N3951. And there has already been an analysis if this could for example replace the Meta Object Compiler(moc) from Qt. This is a very interesting use case for reflection, as Qt did uses its moc-capabilities also for reflection. As C++17 will be a major standard, the proposed changes to keyword syntax could be easily implemented, and so add reflection support to C++.

Modules

This is a feature wanted by so many, that the question is why nobody has yet done it. As of today, there is no single example of how to implement this which is also in use for C++. Clang does currently do some work here, but its version of modules for C++ is currently experimental. There was a very good keynote about modules at C++Now 2012, but since then I haven't seen much about modules at all. As this would be another major impact on the language, I think that C++17 most likely will not support modules. But maybe this will change in the coming year, and C++17 adds first support for modules to C++...

What I learned from reading proposals

Reading through the proposals for 3 C++ Committee meetings last year took me nearly 9 weeks. It is really incredible exhausting to read through all of the proposals en bloc, 6-8 a day. I have learned that the C++ Standardization is a very complex process, dealing with many different issues. Its not just C++ as a 'pure' language, there is also the Standard Library, and of course the many vendors and implementers. As often Standardization is guided by existing technology, there are also different approaches to the same problem. Concurrency is a good example for this, as there are existing and now for standardization partly competing technologies such as OpenCL, OpenMP, C++AMP, Cuda plus libraries such as TBB or PPL. I think that creating out of all papers for a certain field a technical specification is a very clever move. This allows further discussion and improvement before adding a certain feature to the standard.

What I also learned is that the C++ Standard and especially it being an ISO Standard has its costs. The C++ Committee consists out of the Committee, 4 Working Groups and 13 Subgroups such as concurrency, modules, i/o, networking,...

... but wait, there is more! The I in ISO stands for international, so every country in the world has its own national standardization body, which can vote in a C++ Committee meeting. Another part of the Committee are the already mentioned vendors of C++ Compilers and a few other other corporations such as Google. The interest in C++ standardization is rising, so that more and more people are involved in it. Which is very good, as I think it should improve the quality of the standard. On the other side, it will most likely not speed up the process.

Which brings me to the point of adoption of new language features by the vendors. Currently GCC and clang offer full C++11 support, GCC has still some library issues such as full regex support. Other vendors will hopefully be able to catch up until 2016/17 with fully supporting C++11 and C++14. Clang has already full language and library support for C++14 now. With a new major C++ Standard every 5 years, this means that projects should move also every 5 years to the previous, now widely adopted C++ Standard version in my opinion. Tools like clang-modernize can help to bring legacy code into the modern era. The coming years will be very interesting in C++ land.

Join the Meeting C++ patreon community!
This and other posts on Meeting C++ are enabled by my supporters on patreon!