3 ms·
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 co
by josephg 3y ago
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.
- WalterBright 3y agoThose 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.
- Gibbon1 3y agoI 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.
- gpderetta 3y agoWhich 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.
- josephg 3y agoYep. 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.)