TITLE: managing include files via the gaurd idiom

(comp.lang.c++.moderated, 2 Apr 97)


OLIVA: oliva@dcc.unicamp.br 

> I think the point is not exactly about a single file being included
> several times in a single compilation unit.  Build time can be
> increased if *every one* of 2,000 C++ source files #include's
> "config.h", and "config.h" #include's (directly or indirectly) all
> 2,000 corresponding include-files.  You'd get a noticeable improvement
> in build time if you only forward-declared classes whose definition
> were not necessary, and factored out the #include's into different
> include-files.


HYSLOP: jim.hyslop@leitch.com (Jim Hyslop)

I recently was using Borland to build what I considered a small-to-
medium-sized Windows NT app.  It was quite informative to watch the 
progress indicator, which displayed the total number of lines 
compiled.  A full build would hit well over one-and-a-half million 
lines compiled, most of which was taken up by parsing and re-parsing 
the same header files over and over (my source files were in the 
neighbourhood of 10,000 lines total, as I recall).  Sometimes, I 
needed to examine the pre-processed version of the source file (to 
figure out exactly how some macros got expanded) and I was amazed at 
the amount of recursive and repetitive inclusion, especially in the 
stl!

Even with #ifndef...#endif guards, the compiler still has to wade 
through the entire header file to find the matching #endif; 
considering the size of some of the stl headers, that's a lotta 
wading!

It occurred to me that compile time might be shortened considerably 
with a little extra work up front, namely:
- to move all the standard include files into a subdirectory, for 
example c:\bc5\include\realheader
- to create "shell" include files in the standard directory, in this 
case c:\bc5\include, with conditional guards, such as:
  // shell file for iostream.h
  #ifndef MY_IOSTREAM_GUARD
  #define MY_IOSTREAM_GUARD
  #include <realheader/iostream.h>
  #endif
It wouldn't be too hard to write a small batch file (two lines) and 
header creation utility (less than 50 lines of C++, I would guess) 
which would move the file to the subdirectory, then create the shell 
file.

Using this technique, the second and subsequent time a header was 
#included, the compiler would only have to parse 4 lines (5 if you 
really put in the comment).  I never got a chance to try my idea to 
see if it would help speed up compiles; anyone have any thoughts on 
this?

KANZE: James Kanze

>     [A number of compilers recognize the guard idiom, and don't even
>       open the file the second time around, much less wade through its
>       lines.  -- jak ]