Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!rutgers!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: Recursive #includes
Keywords: recursive includes, modularity
Message-ID: <9727@smoke.BRL.MIL>
Date: 26 Feb 89 05:54:03 GMT
References: <570@marob.MASA.COM>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 34

In article <570@marob.MASA.COM> samperi@marob.MASA.COM (Dominick Samperi) writes:
>#ifndef H_FOO
>#define H_FOO
>defines, declarations, etc.
>#endif

That is a good, commonly used scheme.

>I suspect that it will also encourage the inclusion of files that are
>not even needed ...

That hasn't been my experience.

>Furthermore, permitting recursive includes may tend to smear the
>separation between modular components of the software system, and
>designing a correct makefile will be a mess.

If a module's interface depends on another's, then necessarily you
have to #include the other module's interface definition just to
properly declare this one's.  Of course most modules (packages)
should not have interfaces that are tied to others, but sometimes
it is necessary.

It's easy to get the Makefile correct; just declare that a header
depends on the others that it #includes.

>These problems, together with the discovery that some preprocessors
>consider any recursive include to be a fatal error, have motivated me
>to discontinue the use of this trick, and discontinue the use of
>recursive includes as well.

Any such preprocessor is badly broken.  K&R 1st Edition imposes no
such constraint.  How about telling us what brands of compiler have
this problem, so we can avoid purchasing them?