Topic: precompiled headers" [was: Is C++ another dinosaur?]
Author: roger@genie.UUCP (Roger H. Scott)
Date: 20 May 94 03:39:14 GMT Raw View
In article <1994May17.175451.14851@Synopsys.Com> jbuck@synopsys.com (Joe Buck) writes:
>Unfortunately, the design of C and C++ make it very difficult to do
>precompiled headers in a general way.
Having added more than a few grey hairs to my head designing and implementing
a form of "precompiled headers" for C, I can't disagree with the characterization
"very difficult". On the other hand, it *is* possible (especially if you
know when to give up and *re*compile when things get too hard).
> The problem is that #include
>causes the included file to be inserted at that point in the processing of
>the outer file, so that the parsing of that file depends on whatever
>#define directives, typedefs, and previous declarations are in scope.
Yes, yes, but all of this stuff can be dealt with - you just need to "label"
the stuff you save away as the "precompilation" result with the "signature"
of the (relevant) stuff that came before it.
This feature of include files is certainly not a "problem" for programmers -
without it you wouldn't be able to have one include file's contents build on
the contents of previously included files, as in
#include "base_class.h"
#include "derived_class.h"
>This makes it very difficult for a compiler to determine, given an
>#include directive, that it can use a previously compiled form of the
>included file.
See above.
>...
>#import would be very similar to #include, with the following differences:
First off, why don't we make this a syntactic directive rather than a lexical
one? Something like ``import "some_file.h";''.
>1. Any text, definitions, etc processed before the #import line would have
>no effect on the processing of anything in the included file (iostream.h,
>in the example).
As explained above, this is simply not useful.
>2. A second #import of the same file would have no effect.
This is a minor issue, although it would be nice. Of course, things are never
simple - define, precisely, the phrase "the same file" in a platform-independent
way.
The biggest problem we hit with "precompiled" headers was the "flexibility"
with which people could place #include directives among other syntactic
constructs. Among the saner variations are
struct some_machine_generated_thing {
#include "generated_member_list.h"
};
and
enum some_enum {
FIRST,
SECOND,
#include "most_of_the_enumerators.h"
LAST
};
An "import" pseudo-declaration would be *syntactically* constrained to only
occur at the top level ("file scope").