Q&A: Bjarne Stroustrup previews C++ 17

The new version due later this year will feature parallel algorithms, but Concepts, modules, and co-routines will have to wait for a future upgrade

Q&A: Bjarne Stroustrup previews C++ 17

Bjarne Stroustrup created the C++ language in 1979, and it still scores high in language popularity indexes today as it expands into mobile development.

The next version of the language, C++ 17, is due later this year, and while his expectations of what will be in the upgrade have changed since late 2014, Stroustrup still sees useful improvements coming, including parallel algorithms. InfoWorld Editor at Large Paul Krill recently asked Stroustrup his perspectives on the planned upgrade.

InfoWorld: When will C++ 17 be available?

Stroustrup: C++17 will become official some time in 2017, probably in the fall. The major implementations are likely to be ready then or even before. Parts are shipping already.

InfoWorld: What do you see as the major new features?

Stroustrup: Define "major." I consider a language feature or a library component major if it affects the way you think about programming and affects how you structure your code. With that definition, sadly, my answer must be: For most people, I don't see anything major in C++17. Please don't pull "I don't see anything major" out of context as a pullquote or a title; that would be inaccurate and unnecessarily inflammatory. I like the file system library and the parallel algorithms. They are useful and will make some tasks easier for many, but I don't consider them major.

However, many of the features that I consider major are available in some form or other today. The major features are appearing as TS (Technical Specifications). For example: concepts, networking, more concurrency stuff, ranges (Standard Template Library 2), modules, coroutines. Can we say that these are part of C++17? Not really. They will not be part of every C++ implementation, but they exist.

InfoWorld: Which of these improvements in C++ 17 will have the most impact on developers:

  • (parts of) Library Fundamentals TS v1
  • Parallelism TS v1 * File System TS v1
  • Special math functions
  • hardware_*_interference_size * .is_always_lockfree() * clamp()
  • non-const .data() for string

Stroustrup: It depends who you are and what you are doing. For me, I suspect the parallel algorithms will be the most important and having the file system library will be a nice convenience. For some, optional, any, and string_view from the Library Fundamentals will be significant. There are also many small improvements all over the standard library. If you do serious math, the special math functions (Bessel functions) are essential, so it is good that they are now in the standard.

InfoWorld: Will all facets of C++17 be known in July?

Stroustrup: I hope so. We have a number of smaller proposals to decide about in Oulu, Finland, in late June 2016. For example:

With a bit of luck, most will make it; then again, we can't be sure about anything until the votes are counted. The committee strives for consensus, so it doesn't take many objectors to keep a proposal out of the standard. A "no" vote counts about as much as five "yes" votes. Should we get most of those, C++17 will become much more interesting compared to what was approved at the March 2016 meeting.

InfoWorld: With the addition of constexpr lambdas in C++ 17, does C++ continue to become more of a functional programming language? What does that mean for C++ developers?

Stroustrup: Since the introduction of the STL (Standard Template Library) -- about 1994 -- there has been a steady and cautious increase in the use of functional programming techniques in C++. Constexpr lambdas is simply an extension of the set of features that can be used at compile time, rather than something specifically functional. You can now also have loops in constexpr functions, and through that in constant expressions. If the "structured bindings" proposal is accepted for C++17, functions with multiple return values will become easier to use, much as such functions are used in functional programming.

InfoWorld: Apparently, Concepts, for improving compiler diagnostics, won't make it into C++ 17 after also not making it into previous releases. Is this a big disappointment?

Stroustrup: Yes, for me at least, it is a huge disappointment. Together with Gabriel Dos Reis and others, I have worked on this problem for a couple of decades, on this particular approach since 2004, and we have had Andrew Sutton's implementation to play with for about three years. I consider it ready for a standard release next year, but a large number of committee members disagreed for various reasons. A concept is simply a compile-time predicate on a set of types and values. I consider "better error messages" a most useful consequence of the fundamental advantage of Concepts: We can specify the requirements of our generic code (templates) on its arguments. This leads to better designs, better interfaces, the ability to use simple overloading, simpler implementations and potentially more efficient code (through simpler code). Concepts will do for generic code what function argument declarations -- function prototypes -- do for ordinary code using functions.

InfoWorld: Can you answer the same question about modules and co-routines, which also won't make it in?

Stroustrup: I would have liked to get modules for better protection against changes in some components context (such as protection against macros) and better compiler speed, but that proposal isn't ready for C++17, so it goes into a TS. I think that eventually, modules will become massively important. They address long-standing problems in C and C++. An early version currently ships as part of Microsoft's C++. A different variant, more friendly to macros, is available in some versions of Clang. I am disappointed that stackless co-routines are being put into a TS rather than directly into the standard itself. I think they are ready and important for a few critical use cases (pipelines and generators). An early version currently ships as part of Microsoft C++.

InfoWorld: Why didn't you delay shipping the standard for a year and get concepts, modules, and co-routines into the release?

Stroustrup: I was asked that question [before]. My answer was roughly, no, we must ship C++17 as promised. A delay will set a very bad precedent and cause more delays in the future. If C++17 became C++18, I suspect that C++20 would become C++22 or C++23 and we would be well on our way back to the 10-year cycle for ISO standards.