Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!agate!bionet!apple!bloom-beacon!tut.cis.ohio-state.edu!cwjcc!hal!nic.MR.NET!xanth!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: <5151@thorin.cs.unc.edu> Date: 8 Nov 88 01:10:21 GMT References: <5078@thorin.cs.unc.edu> <7573@nsc.nsc.com> <8370@nlm-mcs.arpa> Sender: news@thorin.cs.unc.edu Reply-To: coggins@cs.unc.edu (Dr. James Coggins) Organization: University Of North Carolina, Chapel Hill Lines: 104 Responses to some followups to our Managing C++ Libraries series... ---------------------------------------------------------------------- In article <7573@nsc.nsc.com> rfg@nsc.nsc.com.UUCP (Ron Guilmette) writes: >OK. So how about a slightly more intelligent pre-processor which would > ... nice capabilities deleted ... In article <8370@nlm-mcs.arpa> mjr@vax2.nlm.nih.gov (Marcus J. Ranum) writes: >How about a pre-processor designed for C++ from the start ? Not that I >propose to go off tomorrow and write one... > ... more interesting ideas deleted ... Our objective in "Managing C++ Libraries: Dependencies and Headers" was to present a practical scheme that would work under the current c++ implementation, which we did. But if you want to discuss possible changes... Several lines of argument can be marshalled to support the proposition "C++ should get rid of cpp!" Less fanatical versions of the proposition would permit file inclusion, and also perhaps limited forms of symbol definition and conditional compilation. I remember that complexities in cpp make precompilation of header files impractical, and I heard at the C++ conference some other features or language simplifications that would be nice to have but are impractical due to cpp. (Edit the subject line and jump right in, folks!) ------------------------------------------------------------------------ >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: I'm glad you have a scheme that you can use. However, it does not satisfy the objectives we stated as well as the scheme we presented. I'll show you below where I found problems when we examined this method. (most of which is described as a rejected option in our article): >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! (Our approach involves less invasion into files containing C++ code and isolates administrative stuff in the dependency (.d) files while maintaining lots of flexibility. Concerns of coding and library administration are separated into different 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! Strike two: I have to specify path names?!? I don't want to have to memorize the entire library directory structure! (Our approach uses symbols to specify dependencies; only in the library's prelude file are associations between symbols and paths established, again minimizing intrusion in the coding process and isolating details of the library's storage structure away from the programmer - who has enough on his or her mind already.) 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). Or other external libraries required for particular classes (yet more administrivia #includes). Strike four: (so I'm not a baseball player) Without a prelude.h file for the library, you have to duplicate #includes in every class that could be handled neatly in the prelude file. >3. In the application code, just insert #includes for the classes or >definitions that are *used*, the dependent ones will be automatically >included. So I can't write a program without knowing the directory structure of the library so I can #include the right header files? No, thanks. Soft links? OK, if you have them, you could store links to all header files in a single directory. Now you still have to enter the #includes with path names. (In our system the only #include in application code is for the library's prelude file, and classes used are specified by symbol definitions - no path names to remember or to type.) Fanatic? Extremism in the defense of simplicity is no vice! (Not bad. Hey - write that down!) >Using this scheme requires minimal discipline, it doesn't require >unusual .d files, or awk scripts. .d files won't be unusual when our scheme catches on. We don't use awk scripts- that was a suggestion for how to produce the prelude file automatically if you wanted to. C++ environment builders might want to make that option available, but since I'm building only one library, I don't need it. So I guess I stand by our original posting (so far). Keep those cards and letters coming, folks! --------------------------------------------------------------------- Dr. James M. Coggins coggins@cs.unc.edu Computer Science Department "Make it in Massachusetts" - ad slogan UNC-Chapel Hill "I made it OUT of Massachusetts" Chapel Hill, NC 27514-3175 - my slogan ---------------------------------------------------------------------