Clang-tidy: http://clang.llvm.org/extra/clang-tidy/
Cppcheck: http://cppcheck.sourceforge.net/
Flint++: https://github.com/L2Program/FlintPlusPlus
Clazy: http://www.kdab.com/use-static-analysis-improve-performance/
Another great, modern C++ feature: `constexpr` functions, methods and compile-time constants have the potential to put most, but not all, macros out-of-business... Macros are powerful for DRYing C/C++ similar code sections which cannot be expressed with templates, lambdas or function pointers, for macro pasting identifiers together and for project configuration management for (ie, kernel hardware support). Defines also don't occupy space but also lose semantic value in debugging because they're computed at compile time and spread out wherever they're used... debuggers encountering `constexpr`s should offer both the computed value and a way to debug or debug (not program code at all) how that value was constructed: gdb and lldb should be able to handle that with plugins.
Here's also how we compile most our code, using both gcc and clang, on both stable and head:
clang++ -std=c++1[14z] -Weverything -Werror -Wno-c++98-compat -Wno-weak-vtables ...
g++ -std=c++1[14z] -Wpedantic -Wextra -Werror -Wformat=2 ...
const isn't the same as immutable. 'const' implies a (mostly) read-only view, not read-only data. That is, C++ does not guarantee that the memory does not change, just that some parts of the code will not change it (and even then, there are ways to get around 'const').
It would be marginally better to be const by default, because there would be less code to consider when analyzing changes to data, but the cost of this feature is much larger than the benefits we'd see from it.
And, to top it all off, dealing with a lot of immutables really requires different syntax and different style. Read through the rust book and then try to do the examples in C++. You can do pattern matching and variant types in C++, but they are ugly and probably slower than what we do now.
Like this?
"The rules are designed to be supported by an analysis tool. Violations of rules will be flagged with references (or links) to the relevant rule. We do not expect you to memorize all the rules before trying to write code."
Introduced in this year's cppcon https://channel9.msdn.com/Events/CPP/CppCon-2015/Writing-Goo...
Ideally, you'd add these as feature flags to the compiler. So me and my team can decide "0 is not a pointer in our code", so we compile with -f0-is-not-a-ptr and with -fdefault-initialiser-0. You can already choose if you want exceptions or not, if you want RTTI or not, if you want floating-point math to be optimised as if you're using real numbers (which can lead to subtle numeric instability) - or if you want the compiler to emit exactly what you've written, and so on and so forth.
Adding more safety options which we can turn on for our code would help us write safer code. We can measure the impact of initialise-with-0 for our case and decide whether to use it or not.
EDIT:
For examples, I'd love to have -Wold-style-cast on all of my compilers. The nullptr example in the article is good too, maybe call it -Wold-literal-null? It would be nice if my compilers could give me hints when std::move might be appropriate, if I might be missing a copy or move ctor, or when I could consider using initialization instead of assignment for members. Maybe this is more of a job for the static analyzer and not the compiler--dunno.