Path: utzoo!attcan!uunet!ncrlnk!ncr-sd!hp-sdd!hplabs!nsc!rfg
From: rfg@nsc.nsc.com (Ron Guilmette)
Newsgroups: comp.lang.c++
Subject: Re: Including header files minimally.
Message-ID: <7860@nsc.nsc.com>
Date: 17 Nov 88 01:54:21 GMT
References: <3561@pt.cs.cmu.edu>
Reply-To: rfg@nsc.nsc.com.UUCP (Ron Guilmette)
Organization: National Semiconductor, Sunnyvale
Lines: 47

In article <3561@pt.cs.cmu.edu> dld@f.gp.cs.cmu.edu (David Detlefs) writes:
>There have been a number of interesting suggestions on how to go about
>including header files only as needed...
>...  It seems to me that the "include-once-ability" of a header
>file ought to be a property of the file, independent of the context...
>...Every so often, someone writes an include file that is really meant to be
>included multiple times...

Ever heard of unix links?

>...If we did want to modify cpp, though, we could
>take care of both situations minimally by recording as we process the
>inclusion of a file all the preprocessor symbols used in #ifdef's and
>the values they had at the time of this inclusion.  We would store
>this list in a table, and when we next included the file, check the
>current values of those symbols.  If they are the same as before,
>don't include the file, otherwise do.

I think that there is semantic muddy-ness to the term "at the time of
this inclusion".  When is that exactly?  At the *start* of the inclusion,
somewhere in the middle, or at the end?  Keep in mind that the defined
values may actually change as a result of the inclusion itself.

My idea was far simpler and far less expensive in compile time.  I
suggested (and still suggest) that cpp could be taught to remember a
list of "already included" filenames.  It could then ignore additional
#include's for any file in this list.  You could easily override this
simple logic by making multiple links to individual header files which
must be included multiple times.

>It would be nice if you could precompile each header file to get a
>symbol table (both preprocessor and language tables -- this scheme
>would require an integrated preprocessor/compiler) ...

I think that you may want to switch over to comp.lang.ada ;-)

>I think we really need something like this to get decent compilation
>performance.

Yes.  That is an issue isn't it.  All the more reason to think about
my suggestion.

-- 
Ron Guilmette
National SemiConductor, 1135 Kern Ave. M/S 7C-266; Sunnyvale, CA 94086
Internet: rfg@nsc.nsc.com   or   amdahl!nsc!rfg@ames.arc.nasa.gov
Uucp: ...{pyramid,sun,amdahl,apple}!nsc!rfg