Xref: utzoo comp.lang.c:23164 comp.lang.c++:5176 gnu.g++:458
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!bloom-beacon!athena.mit.edu!tada
From: tada@athena.mit.edu (Michael J Zehr)
Newsgroups: comp.lang.c,comp.lang.c++,gnu.g++
Subject: Re: A solution to the multiple inclusion problem
Summary: another solution
Keywords: #include c c++
Message-ID: <15316@bloom-beacon.MIT.EDU>
Date: 23 Oct 89 18:04:19 GMT
References: <14240@well.UUCP>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: tada@athena.mit.edu (Michael J Zehr)
Followup-To: comp.lang.c
Distribution: comp
Organization: Massachusetts Institute of Technology
Lines: 35

In article <14240@well.UUCP> nagle@well.UUCP (John Nagle) writes:
>[problem of multiple exclusion, generally solved by:]
>	#ifndef XXX
>	#define XXX
>	...content...
>	#endif
>This works, but on the second inclusion, the file still has to be read and
>parsed, at least by the level of processing that reads "#" statements.
>[slowing compilation, particularly in C++ programs]

>[proposed compiler optimization binding the 'XXX' defined above to the
>included file and not including it a second time.]

there's another solution you can manage without having to get your
compiler vendor to make such an extension:

<foo.h:>
#ifndef FOO
#define FOO
#include "foo_real.h"
#endif

admittedly there's an extra file open for the first time reading
through, and you still have to open files when #including the second
time, but it's not as bad as having to read the entire file in
(particularly if you have some really *large* files).  library files
could be changed to this with relatively little effort and no compiler
changes, and users' header files for large systems could be changed to
work faster *today* without having to wait for the vendors to decide to
do this.

(unless i'm missing something obvious and being really stupid this
works....)

-michael j zehr