The AtomicObject team described well on their website the danger of C++’s richness:
C++ is an immensely rich language. This richness is both a blessing and a curse. A blessing, because of the expressive power and support for several programming paradigms; a curse because this richness means complexity, and there is much to master. C++ is a language to grow with, one for which each experience can teach new features, or better understanding. Since each of C++'s features may interact with the others, learning C++ feels like gradually filling in a not-so-sparse matrix of knowledge formed by the cross product of the C++ feature vector with itself. No serious use of the language should be undertaken without good references at hand.
Since 2011, Microsoft has announced the comeback of C++ in many articles, and Microsoft C++ experts like Herb Sutter gave many talks explaining why C++ is back, mostly recommending the use of modern C++. At the same time, the C++11 standard was approved, and we began to talk about C++ as a new language.
However, in 2011, C++ had a past of more than 30 years. And it’s not easy to convince developers that the new C++ has simplified many frustrating C++ usages and that there’s a new, modern way to improve C++ code.
But unfortunately, all the efforts of the active C++ community and well-known experts were not sufficient. Moral of the story: if you give someone the possibility to do something with a language or a tool, don’t be surprised if they do it.
Today, we need some safeguards to help developers write clean C++ code.
1. A protected compiler mode to use a subset of the language
To benefit from all the amazing effort of the standards committee and the C++ community, we need compilers that allow us to exclude some old C++ features.
It’s true that there’s a big constraint when using the existing C++ libraries, but if we are convinced that C++ will have a very long life, we need to start preparing the transition to modern C++ now.
Existing compilers are not designed to accept only a subset of the language standard. However, after working with Clang as a parser for CppDepend, we can confirm that its modularity, its implementation, and its powerful diagnostics feature could help its contributors develop a version that can be easily customized from the command line to exclude some old features of the C++ standards when compiling our sources.
2. Compiler diagnostics and warnings
We need more diagnostics and warnings to report deprecated usage. Clang already reports many interesting diagnostics related to deprecated usage, and maybe in the future it will offer the possibility to stop the build if some specific diagnostics are reported.
3. Tools
Some tools can help us detect deprecated usage, and they can be integrated into the build process to fail the build if some rules are violated.
Clang-Tidy is a powerful tool for detecting many flaws and deprecated usages. CppDepend integrated it in the 2017 version and also provides a code query language to query code like a database, so you can easily customize your coding rules and detect deprecated usages.
In short, we need better solutions to help C++ developers transition to modern C++.
