When I change a comment in a header file, why does the compiler rebuild everything ?
It’s smart enough to know it’s a comment, right? (Comments have a different color after all). So I would like to have a cool option not to mark a file as “modified” when I just change a comment. Granted, it probably would fail in some cases where macros are over-used or something, but it would work pretty well otherwise, wouldn’t it?
February 14th, 2008 at 7:43 am
My pet-peeve is why are compilers so slow? If the compiler was really fast then it wouldn’t matter if everything got recompiled. Back in the old days we had C compilers that used < 400K bytes running on 8 Mhz computers. The compiler and all its tools, libraries and your source code could now all fit into the L2 cache! You don’t even need main memory. True, it might not be as good at optimization, but for day to day work it would be far more productive.
February 16th, 2008 at 3:12 pm
I suppose the preprocessor could strip all the comments and write the hash of the source file to one of the intermediate files it produces (map/lst/even the .o?). How do they currently decide whether to recompile - by checking the source timestamp against the last .o timestamp and only rebuilding if the source file is newer?
At least you can use stuff like ccache and distcc to (sometimes) speed things up a little.
February 22nd, 2008 at 4:24 am
I’d go even further: it would be great if we could publish only a public interface of classes, and have all private content (methods and members) hiddent from headers ; so that altering the private content of a class would not require recompiling others cpp.
Of course that would require a super-smart-linker able to find all access to the content of the class to fix the offsets of members, or to insert the correct size of the class where required (allocation, arrays, pointer increments and the likes), and templates/STL/Boost would make that even worse. So that’ll be only a crazy dream.
February 29th, 2008 at 3:02 pm
I hear you man, but its not a black/white problem.
Here’s my 2 cents and take this with a grain of salt….
In a monolithic environment might make sense. Sometimes you modify the source from outside IDE (p4 sync, different editor, etc) and this might increase the complexity of the problem.
I know that one can pre-process the file if the file is dirty and compile it only if the pre-processed file differs but that’s only one way to tackle the problem. Another way is to use multiple compiling machines(incredibuild like), multiple compiling threads or faster machines (multicore). Those options can be bundled together
I think, I’m not sure, that even with multiple compiling threads/machines exceptions might occur. If the compiler/linker uses template repository for template instancing and this one it’s not shared between compiling threads unforeseen consequences might occur.
On the other hand Ouate de phoque ( WTF
) do I know, anyway? The fact remains that I have no clue about the things that I don’t know (what other compilers/platforms we might use in the future and what types of curve balls life throw at us - compiler wise). I don’t know what I don’t know. You know what I mean? 
Keep up the good work,
d123.