Hacker News Reader

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

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.

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

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.

I got the feeling that the author's beef with Modern C++ is the same as for any C++ that is template heavy. And to me it is not a new or unique experience (i.e. not limited to Modern C++) to have builds that take 45 minutes to build everything. It can happen in older code and in newer code.

Yes, templates make the compiler work harder (sometimes at least), but badly modularized code with "big ball of mud" dependency structure also makes the compiler work a lot. You don't need fancy features to do that.

"Big ball of mud" dependency structures are common because the most pragmatic quick-fix for so many compile errors it to just whack in a new #include.

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.

>There's tricks

You mean PIMPL?

Yes, I think so, though I was never truly clear on what PIMPL was supposed to mean.

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.

PIMPL means "pointer to implementation" and the reason you and your colleagues are having difficulty with it is because you don't understand it, and therefore should not be using it, or, investing the time to understand it before trying to use it.

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

PIMPL pattern is great for reducing compilation time and creating stable user-facing APIs but it has a runtime cost. The "implementation" part is usually heap allocated and calling its methods have extra overhead of crossing the pointer to implementation barrier.

With the use of link-time optimization, most of the overhead of using pimpl idiom is removed. Both the outter wrapper functions as well as the implementation functions can be inlined, making the function calls effectively like a normal class implemented inside a header.

The heap allocation for the implementation won't be removed by LTO.

I'm inclined to agree that for objects that are going to be created and destroyed very often, especially in tight loops, PIMPL is not an ideal idiom. I wouldn't use it to generate fleeting effects in graphics, for example.

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.

Thw complexity and overheead of PIMPL is justified in one scenario, and one scenario only - when you are writing a shared library and need to maintain a stable ABI. Otherwise it is complete overkill.

In my experience both have been true. That's why you get 10+ minute link times in some projects, so even if you use Incredibuild to compile, it still takes ages to link.

(re 10 minute compile times)

> This is simply a bogus statement

I work on a C++ project and believe me, 10 minute compile times would be great :)

The bogus part is 10 minutes vs a few seconds just because you change to the latest standard.

have you tried ccache? the 5x to 10x improvement isn't a bogus statement in my experience

ccache eliminates spurious rebuilds, but doesn't make compilation of things which actually need to be recompiled any faster. It's basically just a workaround for that Make only uses file mtimes and not the contents to decide what needs to be built.

In theory, agreed. In practice I see a lot of re-compilation in large projects.

ccache doesn't help as soon as you change a popular header file. distcc helps quite a bit, but there was a project I worked on for years where by the end the compile time was 15 minutes after you'd distributed it across 20 machines.

“A Variadic Template A Day Keeps The Job Security In Play”

You should see the code that variadic templates replace.

Say more! I'd like to know what you mean.

Before variadic templates you couldn't define a function template taking an arbitrary number of arguments; what you could do is define N overloads up to a finite large N. This quickly becomes tedious and hard to maintain, so you either write an external generator script, or 'creatively' use the preprocessor. These solutions were also not much easier to maintain and of course would kill compilation times.

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