November 18, 2016
I recently attended a lecture by Bjarne Stroustrup on the future of C++. As someone who hasn’t written any C++ since the days of the C++98 standard, and so still sees the STL as the main feature of the language, I was curious to see what has been developed since then. I knew that it now has lambda expressions and a primitive form of type inference, but not much beyond that. Also, as someone who was exposed to Stroustrup’s book in college, I was curious to see him speaking.
To be honest, I was expecting a cranky, old, cult-like leader figure. But now I don’t have that impression at all. While I still see some hubris there — when asked about possible design failures, he didn’t recognize anything major, besides focusing too much on multiple inheritance —, he seemed to be just a guy who wants to provide the highest possible level of low (or zero) cost abstractions.
As to the future of C++, I’m actually a bit optimistic. It seems that the standards committee has recognized the competition (and here I’m thinking of Rust) and added quite a few nice features to the language. For instance, concepts (which seem to be similar to Rust traits), error types and ranges. And it looks like ASIO is finally making it into the language. It might not seem like much, but for a language that was originally designed as an extension of C (and thus was more-or-less doomed from the beginning) and has accumulated a lot of cruft over the years, it’s understandable that things take a long time.
Stroustrup says that the next challenges for him are concurrency, and complete type and resource safety. I’m excited to see the solutions the committee will come up with, although I’ll probably have to wait a few years for that. After the talk, someone revealed his lack of enthusiasm about the new standards (which are supposed to arrive every 3 years now, according to Stroustrup) by commenting that compiler vendors for embedded devices are very slow at implementing them. Which is a bit of a downer, especially considering C++’s stated goal of being the fastest language around. But at least clang and gcc seem to be very eager to implement the new changes, so there’s no good reason not to try them out if you have access to these compilers.