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 effort from the active C++ community and the well-known experts was 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 where we can exclude the use of 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 prepare the switch to the new modern C++ language from now on.
Existing compilers are not designed to accept only a subset of the standards. However, after working with Clang as a parser for CppDepend, we can confirm that its modularity, its implementation, and its powerful diagnostics feature will help its contributors develop in the near future a version that we can easily customize 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 to us. 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 to detect many flaws and deprecated usage. CppDepend integrated it in the 2017 version and also provides a code query language to query the code like a database, so you can easily customize your coding rules and detect where deprecated usage exists.
To sum up, we need a solution to better help C++ developers switch to the new modern C++.