Path: utzoo!attcan!uunet!pilchuck!dataio!bright
From: bright@Data-IO.COM (Walter Bright)
Newsgroups: comp.lang.c++
Subject: Re: Managing C++ Libraries: Dependencies and Headers
Message-ID: <1749@dataio.Data-IO.COM>
Date: 9 Nov 88 19:35:54 GMT
References: <5078@thorin.cs.unc.edu> <7573@nsc.nsc.com> <8370@nlm-mcs.arpa> <5151@thorin.cs.unc.edu>
Reply-To: bright@dataio.Data-IO.COM (Walter Bright)
Organization: Data I/O Corporation; Redmond, WA
Lines: 60

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:
<<// This is foo.hpp
<<#ifndef FOO_HPP
<<#define FOO_HPP
<<	...	// text of header file
<<#endif // FOO_HPP
<
<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.

<<2. In the text of each header file, for each header that it is dependent
<<on, add the following:
<<#ifndef DEPEND_HPP
<<#include "depend.hpp"
<<#endif
<Strike one: more administrivia in my header file!

Again, it's not in the application code or the application header files. It's
in the LIBRARY header files.

<Strike two: I have to specify path names?!?

I *never* specify path names in #include's. A pox on anyone who does! People
who do this have never ported between VMS, MSDOS and UNIX.
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.)

<Strike three: This looks worse if, as happens in my library, there are
<special situations requiring special administrative actions.  For
<example, consider classes with mutual dependencies (forward class
<declarations required).

Sorry, but I don't see the difficulty here.

<Or other external libraries required for
<particular classes (yet more administrivia #includes). 

In the header for that class, put a #include for the external .h file.
What's the problem?

<Strike four: you have to duplicate #includes in every class that
<could be handled neatly in the prelude file.

Not for every class, for every library *header* file. The #includes form
the documentation of the dependencies of the class.

<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!)

<So I guess I stand by our original posting (so far).
So do I by mine!