Path: utzoo!attcan!uunet!mstan!dff
From: dff@Morgan.COM (Daniel F. Fisher)
Newsgroups: comp.lang.c
Subject: Re: Recursive #includes
Summary: Yes, use nested included's
Keywords: nested recursive includes
Message-ID: <239@mstan.Morgan.COM>
Date: 2 Mar 89 19:04:30 GMT
References: <9736@smoke.BRL.MIL> <2538@goofy.megatest.UUCP> <4329@psuvax1.cs.psu.edu> <2941@hound.UUCP>
Reply-To: dff@Morgan.COM (Daniel F. Fisher)
Organization: Morgan Stanley and Co., NY, NY
Lines: 28

In article <2941@hound.UUCP> rkl1@hound.UUCP (K.LAUX) writes:
>	I suppose, given all the discussion, that it might be best to Not Use
>Nested Includes at all.  Then the only problems (minor) would be to keep the
>MakeFile Dependencies up to date and in sync with the actual Includes in the
>source code module and to get the order of inclusion correct (in case one
>Header File needs something that appears in another Header file).
>
>--rkl

But nested includes obviate the need to know the correct order of inclusion,
which would involve MANUALLY compiling and then topologically sorting an
include file list.  This is far more tedious than simply compiling a list
of make dependencies from the transitive closure of the "source file includes
other source file" relation.  And the availability of automatic header
dependency generation even removes this tedium.  Furthermore, if one only
needs to include those header files that are directly referenced in a given
source file, allowing header files to include those headers that they need,
one need not change the list of included files in any source file unless and
until that source file otherwise changes.  Contrast this with having to add
include lines to a multitude of different source files when a shared header
file changes to require prior inclusion of another header file.  Or consider
the pain involved in transporting a program to a system with a somewhat
different set of LOW LEVEL system header files.  Personally, I'd rather deal
with nested includes.

-- 
Daniel F. Fisher
dff@morgan.com