|[4 earlier articles]|
|Re: speeding up compile times in C++ email@example.com (Steve Glass) (1995-02-03)|
|Re: speeding up compile times in C++ firstname.lastname@example.org (1995-02-04)|
|Re: speeding up compile times in C++ email@example.com (Ronald F. Guilmette) (1995-02-04)|
|Re: speeding up compile times in C++ firstname.lastname@example.org (1995-02-06)|
|Re: speeding up compile times in C++ email@example.com (Anthony T. Green) (1995-02-06)|
|Re: speeding up compile times in C++ firstname.lastname@example.org (1995-02-08)|
|Re: speeding up compile times in C++ email@example.com (1995-02-12)|
|From:||firstname.lastname@example.org (Thomas Breuel)|
|Organization:||NETCOM On-line services|
|Date:||Sun, 12 Feb 1995 10:11:34 GMT|
email@example.com (Shankar Unni) writes:
[C++ precompiled header files]
- one precompiled header per source header. This causes enormous
headaches, especially with inter-header dependencies (macros are a
*BEAR*, as are redeclarations of tags, since most parsers simply swallow
them silently leaving no trace behind).
What is so frustrating about this is that the C++ committee had it in
their power to define C++ in such a way that separate compilation
(including precompilation of header files and definitions) would have
How? By providing language based (rather than preprocessor based)
mechanisms for defining and using interfaces (#include) and for
conditional compilation (#ifdef). The technology for this is
well-understood and pretty simple.
That way, new code could have used the language based facilities
exclusively and allowed efficient separate compilation. Only
old code that still used the old mechanisms would have had to
forgo true separate compilation.
Such facilities could also have enhanced type safety and eliminated
some of the chores of keeping header files and implementations in
But that opportunity was missed. Apparently, features like member
function pointers and multiple inheritance were more fun to work on...
Return to the
Search the comp.compilers archives again.