As announced at CppCon, Bjarne Stroustrup and Herb Sutter have started working on a set of guidelines for modern C++. The goal of this effort is improving how developers use the language and help ensuring they write code that is type safe, has no resource leaks, and is as much as possible free of programming logic errors.
According to Stroustrup:
Our core C++ guidelines makes such code simpler to write than older styles of C++ and the safety can be validated by tools that should soon be available as open source.
The guidelines are available on GitHub and have received contributions from experts at CERN, Microsoft, and other organizations, according to the two main authors. The document, although namely still at version “0.6”, is already pretty large, counting more than 200 pages when printed. It is made of several sections, each focusing on individual language features — such as interfaces, classes, expressions, etc. —, or techniques — such as resource management, generic programming, concurrency, etc. The guideline contains a rather varies set of recommendations, going from basic suggestions such as “Give a class a default constructor” (C.43), and “Avoid magic constants” (ES.45), to more advanced ones, such as “Use a T&& parameter together with move for rare optimization opportunities” (F.25). Each rule comes with a short discussion and code samples showing how it is correctly implemented.
The document also contains a section dedicated to a new “Guideline Support Library” (GSL) that has been developed to make it easier to apply the guidelines and provides a set of common types such as array_view, which can represent ranges, and not_null, which can be used to express the constraint that null is not a valid value for a pointer type. An initial portable implementation of GSL has been contributed by Microsoft.
One interesting aspects of the C++ Core Guidelines is the related effort of building a checker tool able to enforce them. Again, an initial implementation has been contributed by Microsoft and should be made available in binary form next October. In a CppCon session, Microsoft Principal Software Engineer Neil MacIntosh provided more details on such tool, claiming that modern static analysis can go well beyond lint and “find subtle, complex bugs early, identify opportunities to improve performance, encourage consistent style and appropriate usage of libraries and APIs”.
InfoQ has reached out to Bjarne Stroustrup to ask him about the new guidelines.
How would you see the newly announced C++ Core Guidelines as the base for the definition of a restricted set of C++, an often recurring idea in discussion forums, which only contains “safe” or “easy to use” language features? Do you think it could be a first step in that direction?
We have no wish to make a subset language. That would fail. One reason is that the billions of lines of C++ code using older features will not go away any day soon. Another, fundamental, reason is that we need the dangerous/unsafe/low-level/error-prone features to implement the higher-level/safe/easy-to-use features. We must not damage C++’s ability to deal directly with hardware.
The GitHub document, in its current form, runs at more than 200 pages when printed. How would you address the criticism that it is in itself testament to C++ unavoidable complexity?
Any comprehensive list of rules for any language would be hundreds of pages. There will be many more rules and many more pages before we are finished. Had we wanted to be this comprehensive for C or Java we would probably have needed more rules. We are not just concerned with safety. We want to help developers adopt techniques that speed up development, deliver good performance, ease maintenance, use of libraries, etc. Not every programmer will need every rule, and we are not recommending people reading all the rules. The tools will know the rules and point the programmers to the exact rule they break — and the rationale and examples will be right there to provide explanation.