Comment by ryandrake | Hacker News Reader

Comment by ryandrake | Hacker News Reader

I like the proposed ideas, but removing things and making breaking changes might be going too far. Compilers should be smart enough to help. I wish g++ and clang had a "-best-practices" compiler flag: -Wall is not enough. But since you will never get everyone to agree on what subset of C++ is best practice, and what dark corners should be avoided, maybe a set of -Wbest-practice-this and -Wbest-practice-that flags that allow you to pick and choose. Warn yourself when you do things that are not warning-worthy but you nonetheless want to avoid.

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.

Here are some tools you should look into:

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/

The other big change that would be beneficial in (?:Obj)?C(?:++)? would be const-by-default, requiring something like `var` for anything that's truly a variable, since `mutable` has a specific meaning in (?:Obj)?C++. It would be consistent with the theme of least-privilege, and allow for more optimizations of one-time and per-loop iteration values.

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 ...

I would also really like to see C++1[7z] concepts implemented by major compilers, because this will make our code a whole lot simpler by reduce the hacks for runtime and compile-time type checking, and make generic programming much cleaner by being able to constrain requirements via arbitrary bool constexprs.

> const-by-default

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.

https://github.com/isocpp/CppCoreGuidelines

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."

here is the tool https://github.com/Microsoft/GSL

Introduced in this year's cppcon https://channel9.msdn.com/Events/CPP/CppCon-2015/Writing-Goo...

Thanks! I didn't realize that was the tool, I thought it was merely supporting libraries.

Just to be clear, [as far as I understand] it is a template library that does static analysis using the compiler. Kinda the best of both worlds...

GCC has a '-Weffc++' option, which claims to do roughly what you want. Although, it's no doubt using obsolete guidelines these days, since it aims to match Scott Meyers' guidelines from his book. (Yep, same Scott Meyers that wrote this blog post.)

It would be nice if gcc would update the guidelines too, the new effective modern c++ book is very nice

Compilers already break old code. If you specify e.g. -std=c99, you can't omit function return type, or declare argument types like in old C.

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.

Reply on news.ycombinator.com