Hacker News Reader

Comment by Aleman360 | Hacker News Reader

Modern C++ is indeed pretty productive. It's the tooling and compile times that hold it back.

Tooling is getting better, CMake is awesome. Modules would reduce compile times significantly but it seems C++17 won't include them, so we'd have to wait a bit longer.

Perhaps you mean link time? If you're spending a lot of time compiling you are probably suffering from other problems. Most of C++'s issues with compilation come from needing to re-compile entire .cpp files because of a change in a depending .h file. If you properly forward your class declarations instead of including a header in a .h file, don't do template meta meta magic, and think about physical design a bit, your compilation time should be under control.

What I mean by physical design is, if a particular function is prone to be edited constantly, keep that function definition in it's own .cpp file.

of course I'll agree that in this day and age, we shouldn't worry about those sorts of things.

You can usually get a noticeable speedup using unity builds, even when using something like Incredibuild. That suggests that more source files is not the answer. (I am not going to speculate as to why things are this way; it simply appears to be the case.) I'm not sure it makes a great deal of sense to separate compilation time from link time anyway (and you should also consider device reboot or program startup time as well). It all adds up to the same thing: shameful turnaround times.

This has been a problem on every C++ project I've worked on over the past 15 years, and it only seems to be getting worse. And scaled up by increasing team size, that makes it even more of a serious problem.

I hope your parting shot was intended to be that we shouldn't have to worry about this today, i.e., that we should be able to expect more from our tools, and that the current tools are shit. Because we absolutely should worry about it! This is people's time we're talking about. That isn't any less valuable than it used to be.

Often with large C++ codebases the link step can be the bottleneck. Not only it can't be easily parallelized for a single target, but even if you have multiple independent binary targets, the high memory usage of the link step makes it hard to run multiple lds at the same time.

I have seen optimized builds run faster than debug builds simply because many symbols where being removed during optimization speeding up the link step.

But when you do need generics and use templates, you are forced to write lots of code in .h files. There is very little you can do in that case to speed up build times, without resorting to devious things like PIMPL.

Unfortunately, even PIMPL won't help with templated code, unless you resort to manual template instantiation which is tedious.

A lot of C++ compile time is simply generating and optimizing all the code. Modules don't help with this.

Modern C++ style generally requires making a whole bunch of little functions and classes and counting on them to be inlined and SROA'd away. This works remarkably well for runtime, but it exacts a big compilation performance hit simply because you're optimizing so much code.

Interesting anecdote, I was writing a ray tracer recently and instead of using real recursion I tried using a recursive template instead (because who needs i-cache). Basically, every bounce of a ray was a different function with <current_bounce + 1> until <max_bounces>.

The actual ray-tracing code wasn't that long at all, but if you turned max_max_bounces up (say, 100+) "code-gen" time in visual studio blew up to over one minute. That was the moment when I appreciated what everyone was saying about C++ compile times being quite slow if you (mis)use templates.

Reply on news.ycombinator.com