Path: utzoo!utgpu!water!watmath!clyde!rutgers!im4u!ut-sally!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: Experience with making multiple includes harmless
Keywords: cpp
Message-ID: <6853@brl-smoke.ARPA>
Date: 16 Dec 87 21:23:33 GMT
References: <3251@tut.cis.ohio-state.edu>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) )
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 22

In article <3251@tut.cis.ohio-state.edu> lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani) writes:
>Two related products that reused our code have ripped out
>all of this and converted their c programs to explicitly
>list all the header files it needs.
>
>If I had to do it over again I wouldn't do this.  Maybe this isn't
>convincing you, but I'm convinced it's a lousy idea.

I've tried it both ways, and they both have advantages and drawbacks.
The main objections to having the application programmer explicitly
include all the prerequisites are:
	1)  It's sometimes hard to get them in the right order.
	2)  If a header acquires a new dependency, all the
	    applications may potentially have to be modified.
	3)  Documenting header interdependencies is a drag.

The main extra thing one needs to do to make the header-includes-all-
preresuisite-headers approach work slickly is to give each header its
own name space.  On a large current project we're doing just that, by
assigning a unique 2-letter "package prefix" for all visible symbols
that each header declares/defines.  This approach has been working
well so far.