[jbverschoor]

Long compile times are almost always because of bad use of header files which include basically everything, insteda of only the used component. And this sometimes is because of bad separation of concersn / modularization.

[drainyard]

I used to agree with this, but having spent a while in a very good C++ project (by C++ standards), even if we try to always forward declare and not include any unnecessary headers in headers, we still have a clean debug build time of 30-40 minutes. Even changing a single line in a cpp file, will still take around 30-40 seconds at best with incremental builds. I think long compile times are in the eye of the beholder, but often it feels like people have just gotten used to unnecessarily long compile times because they've forgotten how fast computers are and how fast a compiler should be for most of the work except for maybe some of the more complex optimizations in -O3. It kills productivity, and should really be a much larger focus than it sometimes seems to be.

[hohenheim]

Well said, I could not have said it better. Just to add, the productivity boost you get from short build times, in a long run, think of a project you work on for years, will out perform ANY gain you get from using a library, templates, and the like that kills your build time.

[magicalhippo]

We use Delphi at work, just did a full rebuild of our core product, 978015 LOC compiled and linked in 22 seconds on my aging i7 4790k.

[jbverschoor]

If it’s just a single line at a leaf in the deptree, it should only be taking time to link everything together.

Still, long compile cycles are my kryptonite... 0 productivity. Horrible. Back when I was doing java, I patched hibernate to serialize and deserialize the generated code, so startuptimes would be lowered with about 80%.

My setup back then used hot code replacement, but so many people would just simply wait 1-3minutes for every single change...

[flohofwoe]

As soon as you include C++ stdlib headers (even only for the stdlib features you're actually using), you have tens- to hundreds-of-thousands of lines of complex template code in front of your own code, and this in each compilation unit. In the end your own code is maybe one percent of all the code the C++ compiler needs to work through each time something is compiled (depending on how many source files you have, this is also why unity builds - merging all source files into one - are so much faster in C++).

In comparison, CRT headers (when compiled as C, not as C++, as in that case additional C++ bloat is added) are usually a few dozen to a few hundred lines of simple declaration code. Compared to C++, it's very hard to make a C project compile slowly.

[LessDmesg]

"Bad use of header files" is the fault of C++, not the developers. Until Stroustrup fixes the header processing behavior (it's 2019 already...) C++ will not become a sane language to use for new development.

[AlexeyBrin]

> Until Stroustrup fixes the header processing behavior (it's 2019 already...) C++ will not become a sane language to use for new development.

C++ does not have a BDFL like other languages, C++ evolution is governed by a committee. In other words, Stroustrup himself needs to submit any changes he wants to the committee and there is a vote ...

C++20 modules should partially solve the header processing problem, but it will take years until it will become widespread in big companies.

[kgabis]

I'm yet to see a C++ project that compiles as fast as a C one.

[dTal]

About a decade ago I used a Zipit Z2 as my primary machine, as a fun experiment. It had 32 megabytes of RAM. Back then, that meant you could just about run Debian (who needs X11 anyway). Believe it or not, I often compiled software on this thing, and I quickly noticed that projects written in C would generally compile, while C++ builds would invariably choke from memory exhaustion. This was actually the first time I became aware of any difference between the two.

A very educational experience!

[rleigh]

groff does, but it restricts itself to C headers only.