Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!apple!sun-barr!newstop!sun!plx!johnc
From: johnc@plx.UUCP (John C.)
Newsgroups: comp.lang.c++
Subject: Re: A solution to the multiple inclusion problem
Summary: Preventing multiple inclusion: variation, time savings
Keywords: #include c c++ inclusion
Message-ID: <2082@plx.UUCP>
Date: 24 Oct 89 16:49:44 GMT
References: <14240@well.UUCP>
Organization: Plexus Software, Santa Clara, CA
Lines: 57

I also use the multiple-inclusion solution presented by one of the
participants in the discussion, with a minor optimization.  My version:

1) All include files have the following format:

/* file foo.h */
#ifndef FOO_H
#define FOO_H
...contents of foo.h...
#endif

(For "standard" include files, you pick one of the symbols defined in
that file as its tag, say "PASCAL" for Microsoft's WINDOWS.H header.)

2) All _include files_ that include other headers do so as follows:

...
#ifndef BAR_H
#include <bar.h>  /* ...or "bar.h", as appropriate */
#endif
...

3) [The optimization]
It is *not* necessary to do (2) in .C files, only in .H files, because
a .C file is never multiply included (nobody #include's .C files,
right? right?? ).  So, .C files just #include without the enclosing
#ifndef/#endif.


Other remarks:

a) Plexus develops Microsoft Windows programs.  Microsoft's main 
header for Windows programming in C, WINDOWS.H, is about 80 KBytes!
We saw at least a 2x compilation speedup when we instituted
practice (2) above, preventing the re-scanning of previously-included
headers.  WINDOWS.H was being scanned up to five times in certain cases!
This may not affect compilation speed in some environments, but it
certainly does in MS-DOS.

b) Regarding modifications to the semantics of #include (so the compiler
would keep track of which file names had already been scanned), you
might be interested to know that MetaWare's compilers have had a
"conditional include" (C_Include) directive for several years now,
which does exactly this.  Perhaps the preferred language change, if 
any, is to define such a "conditional-include" directive, perhaps 
"#cond_include" or "#c_include".  [How about it, Dr. Stroustrup?]

[My preference is actually for a "compiled definitions" approach,
a la Mesa or Modula-2...]

c) Finally, in response to the argument that it's useful for the second
and subsequent inclusion of a file to have a different (and non-null)
effect, I feel *strongly* that this is an unmaintainable practice
and that there are probably better ways to do anything this is used
to accomplish.

/John Ciccarelli  [...sun!plx!johnc, or johnc@plx.uucp]