Path: utzoo!attcan!uunet!husc6!bbn!rochester!pt.cs.cmu.edu!f.gp.cs.cmu.edu!dld
From: dld@f.gp.cs.cmu.edu (David Detlefs)
Newsgroups: comp.lang.c++
Subject: Re: Including header files minimally.
Summary: Response to Ron's response.
Message-ID: <3614@pt.cs.cmu.edu>
Date: 18 Nov 88 20:19:35 GMT
References: <3561@pt.cs.cmu.edu> <7860@nsc.nsc.com>
Organization: Carnegie-Mellon University, CS/RI
Lines: 52

To Ron Guilmette -- I couldn't seem to send you mail --

I think your idea is a very good quick-and-dirty solution -- easy to
understand, easy to implement.  If someone were to take the sources to
some public domain cpp and implement it tomorrow (which is about all it
would take!), it would get a lot of use.  People *shouldn't* write
include files that are intended to be included multiple times with
different results on each inclusion; that is an obscure practice at
best.  Yet people do do this; at least they have, in include files that
we may have to keep including forever in the name of backward
compatibility.  Your solution, with the links, works.  However, I would
hope that you would agree that it is a least somewhat unsatisfying.

I think your solution and mine fall on a continuum; yours is very easy
to implement, but requires the user to perform two actions he or she
wouldn't normally have to do: use the new flag to cpp (or use the flag
to turn it off when necessary, if not including multiply is made the
default), and making extra links to certain files.  Note that you run
the risk of always using the "don't include again mode," and forgetting
to turn it off when you include a file from an external library that
includes a file that includes file x.h 7 times, each time with a
different preprocessor environment.

My solution requires somewhat more work, but in my opinion, not too
much, and solves all problems, without, I think, too much cost in
performance.  I don't think it is "semantically muddy."  To explain it
again: you include a file.  If this file contains no #if-like
constructs, it will generate the same code every time it is included,
so it will never need to be included again.  If it does have an
#if-like construct, then it may generate different code if it is
included again at a time when the preprocessor symbols that are used in
the #if have different values.  (Obviously, if we #define one of these
symbols before using it, it doesn't depend on the external value.)
While we process the #include file for the first time, we record all
the externally defined symbols uses in #if's, and their values when
they were first used.  If we encounter an #include of this file again,
we include it only if one or more of those symbols has a different
value.

This solution requires no special flags, and always gets it right.
Your solution has the drawbacks I mentioned, but has the virtue of
being simpler to implement, and may be somewhat faster.  Both, I think,
are valid ideas.

Trying to keep the intellectual discourse friendly...


-- 
Dave Detlefs			Any correlation between my employer's opinion
Carnegie-Mellon CS		and my own is statistical rather than causal,
dld@cs.cmu.edu			except in those cases where I have helped to
				form my employer's opinion.  (Null disclaimer.)
--