“I have asked why he did not just write T t; and be done with it. He said that he is used to the T *t = new T(); syntax. Then I pointed out that he has a memory leak. He replied that the runtime will take care of that. Too bad there isn't a runtime in C++ ...”<p>Yikes! I don’t know if I’d call this a “not using RAII” anti-pattern, it’s just sheer ignorance / incompetence of how the language works.
IMHO most of those are not general "C++ anti-patterns", but instead define a personal C++ coding style (e.g. another C++ subset). It's important for teams to have such a coding style / C++ subset, but that doesn't mean that others are better or worse.
strong disagree on printf... maybe there's some modern typesafe C++ way to do the same thing, but format specifiers are way easier to remember than all the ways of modifying iostream.
Most of these are just mistakes you see in code written by novices or non-professionals.<p>Although its symptomatic of a larger issue when working with production C++ codebases, which is that you need a lot of eyes on the code to prevent these mistakes and automated tools only go so far.<p>As always, -Wall, -Wpedantic, -Wextra, and -Werror are your friends. But you should understand the error before you fix warnings (which is what `double x = double(1)` looks like)
The advice about the order of includes is interesting, as it's the exact opposite of my usual habit. I see the point, and I'll definitely consider adopting it.<p>One thing I've been bitten by in the past is that Clang / libc++ on Mac sometimes doesn't require a standard header that GCC / libstdc++ does. I don't think this pattern will fix that, though.
I am not sure about his example of large classes. If "energy()" is an integral part of the model, why shouldn't it be a method of it? Maybe the example is not well chosen, but it looks more like extreme minimalism to me. If there are different kind of models (like Ising and XY), they could all implement the same interface with an energy method. Any views on this?