News for hackers. Stuff that matters.
Re:Speeding up C++ build times by josephg on Sunday April 28, 2024 @08:54PM (#40193311)
It makes sense. As projects grow, the average header file is included O(n) times from O(n) different .cc files - leading to O(n^2) parsed header files during compilation. And thus, O(n^2) work for the compiler.

Merging everything into one big .cc file reduces the compilation job back to an O(n) task, since each header only needs to be parsed once.

Its stupid that any of this is necessary, but I suppose its easier to hack around the problem than fix the problem in the language.

Re:Speeding up C++ build times by WalterBright on Sunday April 28, 2024 @11:37PM (#40194161)
Those problems are fixable with C/C++, but nobody seems to want to do it. They are fixed with dlang's ImportC. You can do things like:

    dmd a.c b.c
and it will compile and link the C files together. ImportC also supports modules (to solve the .h problems).

It's all quite doable.

Re:Speeding up C++ build times by Gibbon1 on Monday April 29, 2024 @05:39PM (#40204443)
I wonder if you could create a pragma in C to do almost the same.

I don't have a good name for it but it would force the compiler to ignore previous definitions. With an 'undo' pragma as well.

Re:Speeding up C++ build times by gpderetta on Monday April 29, 2024 @07:27AM (#40196990)
Which compiler parses the same header file multiple times in the same translation unit? Compilers have been optimizing around pragma once and header guards for multiple decades.

edit: ok, you meant that each header is included once in each translation unit.

Re:Speeding up C++ build times by josephg on Tuesday April 30, 2024 @12:59AM (#40207395)
Yep. Worst case, every header is included in every translation unit. Assuming you have a similar proportion of code in your headers and source files, compilation time will land somewhere between O(n) and O(n^2) where n = the number of files. IME in large projects its usually closer to n^2 than n.

(Technically big-O notation specifically refers to worst case performance - but thats not how most people use the notation.)