Path: utzoo!attcan!uunet!ncrlnk!ncrcae!hubcap!gatech!rutgers!apple!amdahl!pyramid!nsc!datack!altnet!altos86!elxsi!beatnix!rw
From: rw@beatnix.UUCP (Russell Williams)
Newsgroups: comp.lang.c++
Subject: Re: Managing C++ Libraries: Dependencies and Headers
Message-ID: <957@elxsi.UUCP>
Date: 9 Nov 88 17:20:22 GMT
References: <5078@thorin.cs.unc.edu> <7573@nsc.nsc.com>
Sender: news@elxsi.UUCP
Reply-To: rw@beatnix.UUCP (Russell Williams)
Organization: ELXSI Super Computers, San Jose
Lines: 28

In article <7573@nsc.nsc.com> rfg@nsc.nsc.com.UUCP (Ron Guilmette) writes:
>OK.  So how about a slightly more intelligent pre-processor which would
>(a) keep a list of all files included so far, and (b) avoid including
>files which have already been included once (even if they are called for
>again via further #include's)?  This would have the same effect as the
>encapsulation of header files within #ifdef's (which many people are using
>now).
   
   We did this in our Pascal compiler to support construction of
the Embos operating system (several hundred thousand lines of source
code) and found it to work quite well.  We adopted the convention that
all header files include all files on which they depend, so programs
include exactly those header files they use and don't worry about
dependencies.
 
>The only problem is that this approach is *not* compatible with certain tricky
>uses of header files (i.e. those cases when a given header file *must* actually
>be included more than once for some reason).  Maybe this is a good thing.

   We added a "%hardinclude" directive which forces inclusion for these
applications.

   If you're willing to slay the ageing dragon of cpp, many elegant
solutions are possible.

Russell Williams
..uunet!elxsi!rw
..ucbvax!sun!elxsi!rw