Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!tut.cis.ohio-state.edu!snorkelwacker!spdcc!ima!haddock!karl
From: karl@haddock.ima.isc.com (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: A solution to the multiple inclusion problem
Message-ID: <15006@haddock.ima.isc.com>
Date: 27 Oct 89 17:59:31 GMT
References: <14240@well.UUCP> <11396@smoke.BRL.MIL> <288@charyb.COM> <FOX.89Oct26215145@novax.allegra.att.com>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Cambridge, MA 02138-5302
Lines: 19

In article <FOX.89Oct26215145@novax.allegra.att.com> fox@allegra.att.com (David Fox) writes:
>A problem with the idea of having the compiler recognize the
>	#ifndef FOO  #define FOO  ... #endif
>arrangement (I wouldn't call it a construct) is what if the
>including file explicitly #undefs FOO?

The optimization is that the compiler, on first encountering a header H that
fits the pattern `#if EXPR ... #endif', stores the pair <H, EXPR> in an
internal table.  (In your example, the expression is `!defined(FOO)'.)  Any
request to include a file F first checks the table to see if F appears as the
left side of some pair <F, EXPR>, and if so, interprets the request as if it
had read `#if EXPR   #include F   #endif'.  So if the user has disabled the
guard expression, the file will indeed be included a second time, as desired.

(Note also that it's not necessary for the compiler to be able to determine
that two names denote the same file.  If it fails to detect this, then the
optimization doesn't take place, but the semantics are preserved.)

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint