Path: utzoo!attcan!uunet!ncrlnk!ncrcae!ece-csc!mcnc!thorin!proline!coggins
From: coggins@proline.cs.unc.edu (Dr. James Coggins)
Newsgroups: comp.lang.c++
Subject: Re: Managing C/C++ Libraries: Dependencies
Message-ID: <5334@thorin.cs.unc.edu>
Date: 15 Nov 88 14:45:11 GMT
References: <8387@nlm-mcs.arpa> <3414@geaclib.UUCP> <5044@polya.Stanford.EDU>
Sender: news@thorin.cs.unc.edu
Reply-To: coggins@cs.unc.edu (Dr. James Coggins)
Organization: University Of North Carolina, Chapel Hill
Lines: 24

In article <5044@polya.Stanford.EDU> shap@polya.Stanford.EDU (Jonathan S. Shapiro) writes:
>Further, #include_once puts the onus in the wrong place.  The decision
>should be up to the included file, not the includer.  This frees the
>include-file implementor to change the implementation transparently to
>your code.
>
>Jon

I consider a library to be a single entity - a particularly appropriate
assumption in C++ due to the massive interdependencies.  I want the
Library to control how its files are #included, which is what the
scheme I originally presented accomplished.  It also removed concerns
about directory structures and file names from the domain of the
library coder by isolating such administrative concerns outside the code.

I hope you folks can decide something to do about cpp that would make
my whole scheme superfluous.  Until then, it works.

---------------------------------------------------------------------
Dr. James M. Coggins          coggins@cs.unc.edu
Computer Science Department   Working code is EXTREMELY valuable.
UNC-Chapel Hill               That's why ditzy prototypes tend to
Chapel Hill, NC 27514-3175    be difficult to throw away.
---------------------------------------------------------------------