Path: utzoo!utgpu!attcan!uunet!ncrlnk!ncrcae!ece-csc!mcnc!thorin!retina!coggins
From: coggins@retina.cs.unc.edu (Dr. James Coggins)
Newsgroups: comp.lang.c++
Subject: Re: Managing C++ Libraries: Dependencies and Headers
Message-ID: <5220@thorin.cs.unc.edu>
Date: 10 Nov 88 16:22:48 GMT
References: <5078@thorin.cs.unc.edu> <7573@nsc.nsc.com> <8370@nlm-mcs.arpa> <5151@thorin.cs.unc.edu> <1749@dataio.Data-IO.COM>
Sender: news@thorin.cs.unc.edu
Reply-To: coggins@cs.unc.edu (Dr. James Coggins)
Organization: University Of North Carolina, Chapel Hill
Lines: 42

In article <1749@dataio.Data-IO.COM> bright@dataio.Data-IO.COM (Walter Bright) writes:
>In article <5151@thorin.cs.unc.edu> coggins@cs.unc.edu (Dr. James Coggins) writes:
><<From: bright@Data-IO.COM (Walter Bright)
><<While the scheme presented is interesting, I find it unnecessarilly complex.
><<Here's the scheme I used which satisfies the basic requirements:
><<1. In each header file, put a 'wrapper' around it of the form:
><
><Call me a fanatic, but I don't like this wrapper business. Get this
><administrative stuff out of my code!
>
>It's not in the application code or the application header files. It's
>in the LIBRARY header files.

But I (and many others out there!) are primarily LIBRARY DEVELOPERS.
Library header files ARE my code.  And I still don't want this
administrative stuff cluttering it up. 

>I use -Ipath on the command line or set the INCLUDE environment variable.
>(As a matter of personal taste, I also dislike the "1 subdirectory per
>class" style, I find I spend more time cd'ing than doing useful work.)

If you are working on small enough projects to keep your code in one
directory, and you aren't bothered by administrivia in your (library)
code, and you are unable or unwilling to modularize in such a way as
to minimize the directory switching that is required, then you may
disagree with our approach with my best wishes. 

><Fanatic?  Extremism in the defense of simplicity is no vice!
>Hey, I claim that my system is simpler than yours! (Obviously a matter of
>opinion!)

Not for library developers.

Anything works on small projects.  On larger projects both of our
header management schemes address the principal issues.  My approach
is marginally superior for library developers because it eliminates
clutter from the code and decreases memory load on the library
developer.  Not an earth-shaking improvement over your management
scheme, but it's there. 

James Coggins
coggins@cs.unc.edu