Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!husc6!purdue!decwrl!nsc!rfg From: rfg@nsc.nsc.com (Ron Guilmette) Newsgroups: comp.lang.c++ Subject: Re: Managing C++ Libraries: Dependencies and Headers Message-ID: <7775@nsc.nsc.com> Date: 13 Nov 88 18:55:18 GMT References: <5078@thorin.cs.unc.edu> <7573@nsc.nsc.com> <8370@nlm-mcs.arpa> <5151@thorin.cs.unc.edu> Reply-To: rfg@nsc.nsc.com.UUCP (Ron Guilmette) Organization: National Semiconductor, Sunnyvale Lines: 73 In article <5151@thorin.cs.unc.edu> coggins@cs.unc.edu (Dr. James Coggins) writes: >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... Please, if you are going to quote me then I think it would be nice to include the idea I proposed. Which can be summarized in about 1 line, thus: Add a flag to cpp which would cause it *not* to re-include any file already included. >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. At this point in time, I think that it would be a mistake for anyone to start up a new enterprize to manufacture vinyl-record cleaning kits. Lets face it, the world is going CD. Likewise, the situation with C++ is fluid and evolving. The approach I suggested requires a minor evolution of cpp, but is nonetheless largely compatible with current tools and practices. >Several lines of argument can be marshalled to support the proposition >"C++ should get rid of cpp!" Less fanatical versions of the proposition... Is this belief now considered fanatic? Count me in anyway. >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.) Ah, ha! Another fanatic. Well, I don't like that wrapper nonsense either, but my approach involves *NO* invasion into files containing C++ code (if you're already using #ifdef wrappers in your .H files you may want to delete that junk, but you don't have to). Further, my approach requires *NO* administrivia anywhere and has just as much "flexibility" as yours does. So there! :-) One potential problem with my solution (noted in a message to me from M. Tiemann) is that some preexisting code may be written which REQUIRES multiple inclusions of the same single header file. I have two counter arguments: First, my idea is to have cpp work just like it always has (read "backward compatibility") *unless* you give it the new option (perhaps indirectly via CC or g++). Second, even if there were no option, and if cpp *always* prevented multiple inclusions of the same single file, you could easily setup your makefiles so that they made multiple links (in your source directory) to each such rogue header file. Thus, you could easily fool such a modified cpp into believing that it is including different files when it is in fact including the same file multiple times. >>Using this scheme requires minimal discipline, it doesn't require >>unusual .d files, or awk scripts. This is true for my scheme also. >So I guess I stand by our original posting (so far). I admire anyone who stands by his convictions even in the face of good evidence to the contrary. :-) -- Ron Guilmette National SemiConductor, 1135 Kern Ave. M/S 7C-266; Sunnyvale, CA 94086 Internet: rfg@nsc.nsc.com or amdahl!nsc!rfg@ames.arc.nasa.gov Uucp: ...{pyramid,sun,amdahl,apple}!nsc!rfg