Just an anecdote, but I also work at a successful HFT as well modern C++ is almost everywhere, without any performance hits and much cleaner code. Often it's easier to write fast code with it.
FWIW, I have been on the industry only 3 years so far, but I also see modern C++ and boost everywhere. I'm aware of the obvious selection bias, but then again it also applies to the author: if a firm has to call an external consultant to make sense of their codebase, it wasn't probably very good to start with.
C++ is worse than most languages in this way, because private members are defined in public headers. This forces you add #includes to the headers. Thus the #include graph is much denser than the true dependencies in your program.
There's tricks for getting around this, but they aren't always practical; and they go against the grain of the "every class has its own .cpp and .h file" rule, which lots of people want to insist on.
You mean PIMPL?
I am referring to writing a base class in the header and then doing the actual implementation in a derived class visible only inside one .cpp file. There are some other tricks you can do too, such as using pointers-to-incomplete types.
When I do any of these tricks, find that someone else later comes and makes a changes that introduces the extra #includes after all.
>every class has its own .cpp and .h file
Wrong. There are so many high-quality and widely-used libraries that are "header only".
>When I do any of these tricks, find that someone else later comes and makes a changes that introduces the extra #includes after all.
It is possible to write sloppy code in any language, and also to receive low-quality contributions from anyone else to your code. This is not unique to C++. That's why it is important that everyone in a team be on the same page about how code is organized.
>I am referring to writing a base class in the header and then doing the actual implementation in a derived class visible only inside one .cpp file.
This is not the PIMPL idiom, though it is halfway right.
For objects that are used in setting up parts of a system and that will persist for long periods of time, maybe even the lifetime of the app, PIMPL is particularly well-suited for such classes. Classes that might manage networking, or encompass an entire part of app's running architecture, etc.
> This is simply a bogus statement
I work on a C++ project and believe me, 10 minute compile times would be great :)
The worst part is that often these were forwarding functions, that is, they didn't do anything directly with their parameters, but simply forwarded them to some other function (this happen surprisingly often in highly generic code). To do forwarding correctly, you have to handle const and non const reference arguments properly, which means that N overloads are not enough and you need N*2^N (someone please check my math) overloads. As you can imagine, this was impractical for N > 3.
Variadic templates plus perfect forwarding via magic references make easy, practical and possible what was impractical before.
edit: spelling
>It is not rare to see Modern C++ applications taking 10 minutes to compile. With traditional C++, this number is counted in low seconds for a simple change.
This is simply a bogus statement with respect to what at least 90% of c++ developers do on a daily basis.
I have benchmarked unique_ptr, auto, brace initialization, lambdas, range-based-for and other modern idioms and found them all to be at least as fast, and often faster, than their older counterparts. Now, if I were to instead go off and write template-heavy code using new features, that would be different. But in reality, the vast majority of c++ developers -- I'd wager at least 95% -- are not writing variadic templates on a daily basis (nor should they be).
The memory safety and many benefits from unique_ptr [0] is one of many modern tools that is a non-brainer to use in nearly all contexts. No, not nearly all contexts, allow me to rephrase: all contexts. It just is, and if you compare its use to manual new/delete code, the benefits are solid and faster.
The author further claims that modern C++ is less maintainable and more complex. The absolute opposite is true in nearly all cases. Using unique_ptr again as an example, it leads to less code, less complex code, more clear code, and better maintainability and code readability. Uniform brace initialization is another example that prevents many common older problems in the language.
FYI the author keeps talking about high frequency trading as an example of why modern c++ is a bad choice. Well, I worked at a HFT firm for a long time until last year, the firm places millions of trades per day and is among the most successful in the markets it trades. And what did we use? Only modern features. Lambdas, auto, unique_ptr, range-fors, even std::async -- everywhere in our code. This author is either naive or political.
I think the title of this article is highly misleading, and the contents are not relevant. Overall, this article is just bad advice for most of us.
[0] https://news.ycombinator.com/item?id=11699954