Bjarne Stroustrup, designer and original implementor of C++, has recently circulated a draft aimed at “stimulating a discussion” about C++17 design goals and possible new features. According to Stroustrup, C++17 will have three design goals:
- Improving support for large-scale dependable software.
- Providing support for higher-level models for concurrency.
- Simplifying the core language.
For each of the design goals above, Stroustrup lists new features that could make it into C++17. Here are some of the possible features that are among Stroustrup’s preferred features:
- modules to improve locality and compile time;
- contracts to improve specification;
- type-safe unions, probably based on functional-programming style pattern matching;
- concepts
- ranges
- uniform call syntax to simplify the specification and use of template libraries;
- co-routines, i.e., resumable functions;
- SIMD vector to better exploit modern hardware.
Stroustrup warns, though, against falling into the trap of believing that “a list of more or less related language features and standard-library components” can provide an articulated description of what C++17 is supposed to become. What matters is understanding that C++17 is supposed to be a “major release”, as opposed e.g. to C++14, thus it shall contain at least “two or three major features” in terms of their impact on what users do with the language, e.g. concepts, modules, and ranges.
Interestingly, the document also tries to clarify what C++–17 will not be. Specifically, this is what Stroustrup lists as undesirable:
- convert C++ into a radically different language or provide a sort of high-level segregated sub-language.
- add new features to C++ for the sake of competing with “every other language” or having it to support a new “paradigm”.
- increase the complexity of the language or hamper its power for “the most demanding systems programming task.”
InfoQ has taken the chance to talk with Stroustrup.
Could you briefly comment on the list of features for C++17? Have you got a sort of priority list?
Concepts is going the change the way we think about generic programming, making generic programming much more mainstream. Concepts will also address the common - and reasonable - complaints about the quality of error messages. We need to get concepts into the standard library to get the full effect of that.
Modules should dramatically improve compile times and limit the bad effects of overuse of macros, leading to better C++ tools.
Higher-level concurrency models will make writing concurrent code significantly easier and the resulting code will run faster than if people stick with the low-level threads-and-locks way of expressing concurrent code.
These features are ideal because they improve the quality of code by simplifying it.
It seems that thanks to the work that the committee has been doing during the last few years and further work that is being done for C++17, the C++ language is overcoming some of its most debated limitations. This seems to disprove the rather strongly entrenched idea that “design by committee” cannot bring real progress. Would you comment on the work that the committee has been doing? What kind of recipe for success, if any, are you adopting?
You cannot dismiss the problems of design by committee. It is a daunting task to create something new, solid, and coherent by a group of 100 individuals (or 300 individuals if you count the people who take part in the discussions but don’t come to the meetings).
It is amazing that we usually manage. Yes, there are examples that we could have done better. Yes, the committee work can be most frustrating, but there is no way an individual could manage alone at this scale. It is not a question of committee vs. individual, but about how the inevitable committee operates. Few major things in the world today is the work of a single unaided individual.
C++17 confirms C++ nature of being a rather low-level (meaning: enabling very fine-grained control over the language semantics), multi-paradigm, complex language. Still the effort to make it an “easier” language to use is one of the major motivations of the committee’s work. Could you explain what is the philosophy that the Committee is following to make C++ a more accessible language?
Thinking about levels of languages has become a mistake. Think of C++ as a language with an unsurpassed ability to manipulate hardware directly plus a set of abstraction mechanisms that allows us to raise the level of abstraction when needed. Programming close to the hardware is necessary for many important tasks, but not very pleasant. C++ enables zero-overhead abstraction to get us away from the hardware without adding cost. By “zero-abstraction” I mean not a byte and not a cycle wasted compared to hand-crafted low-level alternatives. Often the overhead of a function call (and especially an indirect function call) is considered too much. Offering both hardware access and abstraction is the basis of C++. Doing it efficiently is what distinguishes it from other languages.
I no longer refer to this as “multiparadigm” because I find that term encourages many to simply select one “paradigm” rather than using the full strength of the language. Unfortunately, I don’t have a good buzzword for what I do.
It would probably not be fair to say that a committee had a philosophy. We are many individuals with a wide variety of backgrounds and the views vary. Most agree on the description of C++ as presented above. That’s the foundation of C++ that must not be compromised. We also agree that we must maintain a very strict view on compatibility: The C++ community wants improvements, but they really, really don’t want their billions of lines of code broken in the process. The details of exactly what improvements would be most significant, which are feasible in a reasonable time-scale, and how to express them as part of the language and standard library are crucial. They are hard for a large group of people to agree on, but an agreement is essential. That’s why I wrote my note and why we will have a discussion about it at the next meeting.
I spend so much time on C++ and its standardization because it is a critical part of many industries: computers, semiconductors, transport, telecom, finance, manufacturing, aerospace, entertainment, and more. Look inside most critical systems and gadgets and you’ll find some C++ inside. That, and being able to help science in a small way, through its software systems, motivates me. C++ is a tool meant to be used for building important artifacts.
Stroustrup’s draft is a follow-up to a post circulated previously that elicitated many comments on reddit, Hacker News, The Register.
