psrc@pegasus.ATT.COM (Paul S. R. Chisholm) (02/27/89)
In article <570@marob.MASA.COM>, samperi@marob.MASA.COM (Dominick Samperi) writes: > <contents of foo.h>: > > #ifndef H_FOO > #define H_FOO >...stuff... > #endif This issue was beaten to death a few weeks ago in the comp.lang.c++ news group. The obvious proposal is to not #include a file that's already been #included, even if you see a second (or third, or forty- second) #include for it. This would also be more efficient that what you suggest above, since the file doesn't even need to be opened again, let alone read. Unfortunately, it can break existing C code. We had such a cpp (back in the bad old days of Net 1000, a large development project). People tended to #include the whole world, just in case; but it did speed up compilation quite a bit (we had lots of big header files). The C++ header files I've seen do things like #ifndef STDIO_H, as you suggest above. It may not the best solution, but it works. For more information, look at old comp.lang.c++ articles (no, I don't know of any place that archives them). >Dominick Samperi -- ESCC, samperi@marob.masa.com, uunet!hombre!samperi Paul S. R. Chisholm, AT&T Bell Laboratories, att!pegasus!psrc psrc@pegasus.att.com, AT&T Mail !psrchisholm I'm not speaking for the company, I'm just speaking my mind.
coggins@coggins.cs.unc.edu (Dr. James Coggins) (02/27/89)
In article <2630@pegasus.ATT.COM> psrc@pegasus.ATT.COM (Paul S. R. Chisholm) writes: > >This issue was beaten to death a few weeks ago in the comp.lang.c++ >news group. The obvious proposal is to not #include a file that's >already been #included, even if you see a second (or third, or forty- >second) #include for it. > >Paul S. R. Chisholm, AT&T Bell Laboratories, att!pegasus!psrc I was one of the principal beaters of this topic. My net postings have been cleaned up, enhanced, and submitted to SIGPLAN Notices (no idea yet on publication date). They are also available as a technical report from my department's SoftLab (software research laboratory). You can either watch SIGPLAN for J. Coggins and G. Bollella, "Managing C++ Libraries" or e-mail for a copy of our technical report (which will soon include an addendum with some further techniques) to Pam Payne, Softlab Coordinator at softlab@cs.unc.edu or to the address below. The organization scheme I descibed requires no preprocessor hacks, includes headers once and once only, imposes minimally on the program development process, and is still working well with VERY little maintenance required. In fact, we have extended it recently to handle compilations of my research library for multiple architectures (Sun3, Sun4, Vax780) and are preparing to incorporate RCS support directly into the management structure. (These points will be described in the addendum to the SoftLab TR). USmail for the tech report: Pam Payne, SoftLab Coordinator Computer Science Department CB#3175 University of North Carolina Chapel Hill, NC 27599-3175 --------------------------------------------------------------------- Dr. James M. Coggins coggins@cs.unc.edu Computer Science Department UNC-Chapel Hill Whaat! is the sound of an issue being Chapel Hill, NC 27514-3175 beaten to death! ---------------------------------------------------------------------
dld@F.GP.CS.CMU.EDU (David Detlefs) (02/28/89)
Recently, Paul Chisholm replied to Dominich Samperi's query on this subject, saying that this idea had been beaten to death recently. He went on to summarize the discussion, saying roughly that the two extreme solutions to "the include file problem" are 1) Write "foo.h" in the form #ifndef _FOO_H_ #define _FOO_H_ 1 <contents of foo.h> #endif // _FOO_H_ This requires no modifications to cpp. 2) Build a cpp so that it never includes a file twice -- this increases efficeincy significantly because, unlike the above, it doesn't even have to open the file to determine that it doesn't need to be included. Unfortunately, despite what many of us might think about such usage, some files are written to be included multiple times. Many people in the discussion tried to find compromise solutions; I was one of them. Unfortunately, my idea didn't work. I'm posting to plug what I thought was the best solution I read; I think all cpp's should be written this way (I forget who proposed this -- they should take a bow, I think): When cpp first processes a file, it determines all non-comment, non-whitespace text in the file is enclosed in an #ifndef block, as above. If so, the file name and the variable whose definedness determines inclusion are put in a table. On subsequent includes, the file is opened and processed only if the variable is not defined. This would seem to have all the performance advantages of proposal 2, while retaining all the compatibility advantages of proposal 1. Just a marvelous idea. -- Dave Detlefs Any correlation between my employer's opinion Carnegie-Mellon CS and my own is statistical rather than causal, dld@cs.cmu.edu except in those cases where I have helped to form my employer's opinion. (Null disclaimer.) --
prc@maxim.ERBE.SE (Robert Claeson) (02/28/89)
In article <DLD.89Feb27115937@F.GP.CS.CMU.EDU>, dld@F.GP.CS.CMU.EDU (David Detlefs) writes: > 2) Build a cpp so that it never includes a file twice -- this > increases efficeincy significantly because, unlike the above, it > doesn't even have to open the file to determine that it doesn't need > to be included. Unfortunately, despite what many of us might think > about such usage, some files are written to be included multiple > times. Well, then make it switch configureable with the "new" behavior as the default. -- Robert Claeson, ERBE DATA AB, P.O. Box 77, S-175 22 Jarfalla, Sweden Tel: +46 (0)758-202 50 Fax: +46 (0)758-197 20 EUnet: rclaeson@ERBE.SE uucp: {uunet,enea}!erbe.se!rclaeson ARPAnet: rclaeson%ERBE.SE@uunet.UU.NET BITNET: rclaeson@ERBE.SE