>>15
At the very least, wouldn't one have to do a pass to compile debug info for all modularized code and tell the native linker to use it? The information in the headers can't just be thrown away.
Incidentally, gcc 4 already has the capability to deduplicate
some of DWARF information at the compile phase [1].
>>21
I've often thought of doing something like this, to make it easier to spot bad header dependencies:
#ifdef FOO_H
#error multiple includes
#else
#define FOO_H
/* ... */
#endif
In practice, though, it seems that once the number of headers exceeds 10-20, people become unwilling or unable to keep the includes in topographical order.
[1]
http://gcc.gnu.org/wiki/DwarfSeparateTypeInfo