Path: utzoo!attcan!uunet!husc6!purdue!decwrl!nsc!rfg
From: rfg@nsc.nsc.com (Ron Guilmette)
Newsgroups: comp.lang.c++
Subject: Re: Managing C++ Libraries: Dependencies and Headers
Message-ID: <7573@nsc.nsc.com>
Date: 6 Nov 88 18:12:58 GMT
References: <5078@thorin.cs.unc.edu>
Reply-To: rfg@nsc.nsc.com.UUCP (Ron Guilmette)
Organization: National Semiconductor, Sunnyvale
Lines: 53

In article <5078@thorin.cs.unc.edu> coggins@coggins.cs.unc.edu (Dr. James Coggins) writes:
...
>An ideal solution to the problems of header file and dependency
>management would posess the following characteristics:
...
>7.  A program written using our management system should read only the 
>    header files that are necessary and should read them only once. 
...
>Rejected Approaches
...
>3. Use #ifndef SYM ... #endif [to surround header files]
>   A common solution in practice...
...
>... This is a reasonable solution, which
>we rejected for several reasons.  First, this system allows a header
>file to be #included many times - it will be processed only once, but
>we prefer that it not be touched at all if it is not required.
...
>...  Third, we find the intrusion of the
>#ifndef...#endif directives in our header files aesthetically
>displeasing.  We prefer a less invasive approach.

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).

Such a scheme could be implemented very easily (say in the GNU pre-processor)
and it could either be made the default action, or it could be invoked (only
when desired) via a new pre-processor option.  It would meet most of the
stated requirements (with the possible exception of the somewhat vague "good
software engineering" requirement).

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.
Such "tricky" uses of header files are probably not compatible with "good
software engineering practices".

>We have found this to be a minimal level of invasion in the process of
>preparing a .c file, and while our scheme is rather costly to set up,
>it appears to be easy to understand and maintain.

I like mine better :-)  I think that it more fully satisfies the KISS
principal.

-- 
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