Path: utzoo!attcan!uunet!husc6!bbn!rochester!pt.cs.cmu.edu!f.gp.cs.cmu.edu!dld From: dld@f.gp.cs.cmu.edu (David Detlefs) Newsgroups: comp.lang.c++ Subject: Including header files minimally. Message-ID: <3561@pt.cs.cmu.edu> Date: 11 Nov 88 19:26:55 GMT Organization: Carnegie-Mellon University, CS/RI Lines: 47 There have been a number of interesting suggestions on how to go about including header files only as needed. Someone suggested including them using something like an #include_once directive. It seems to me that the "include-once-ability" of a header file ought to be a property of the file, independent of the context in which is included. This would favor putting something in the file itself. The "#ifndef/#define//#endif" style, while not pretty, is certainly sufficient and requires no modifications to cpp. Every so often, someone writes an include file that is really meant to be included multiple times -- it contains #ifdef's that depend an symbols whose values are changed between inclusions. Files of this kind could not be include-once. If we did want to modify cpp, though, we could take care of both situations minimally by recording as we process the inclusion of a file all the preprocessor symbols used in #ifdef's and the values they had at the time of this inclusion. We would store this list in a table, and when we next included the file, check the current values of those symbols. If they are the same as before, don't include the file, otherwise do. It would be nice if you could precompile each header file to get a symbol table (both preprocessor and language tables -- this scheme would require an integrated preprocessor/compiler) that you would dump to a file. Maybe you would call this a ".hx" file. Whenever you include a .h file, check for a corresponding .hx file in the same directory. If you find it, look at the .hx file; in there, you've recorded this same list of external preprocessor symbols it depends on and the values for those that were used when this was compiled. If they agree with the current values for those symbols, then you just read in the file. (I have some ideas about how to dump/undump the symbol table, but that's another discussion.) I think we really need something like this to get decent compilation performance. The project I work on requires all programs written in the the language we're writing to include a file that expands to upwards of 3500 lines of code. Compiles take on the order of 5 minutes on an IBM RT/PC. Not very good. I'd like to see if some scheme like the above could make this better. -- 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.) --