Xref: utzoo comp.lang.c:23375 comp.lang.c++:5257 gnu.g++:485
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!kddlab!titcca!sragwa!wsgw!socslgw!diamond
From: diamond@csl.sony.co.jp (Norman Diamond)
Newsgroups: comp.lang.c,comp.lang.c++,gnu.g++
Subject: Re: A solution to the multiple inclusion problem
Message-ID: <11015@riks.csl.sony.co.jp>
Date: 27 Oct 89 00:31:09 GMT
References: <14240@well.UUCP> <11396@smoke.BRL.MIL> <1989Oct25.164145.29980@utzoo.uucp>
Reply-To: diamond@riks. (Norman Diamond)
Followup-To: comp.lang.c
Organization: Sony Computer Science Laboratory Inc., Tokyo, Japan
Lines: 29

Someone:

>>>      I propose a solution via compiler optimization.

In article <11396@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes:

>>Your solution does not at all seem to me to preserve existing semantics.

In article <1989Oct25.164145.29980@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:

>Can you elaborate on this, Doug?  Seems to me like what he was proposing --
>have compiler recognize files bracketed with `#ifndef FOO_H' and remember
>the bracketing -- comes under the "as if" rule.  Re-including such a file
>with FOO_H defined cannot possibly have any effect except to slow down
>the compilation.

I mostly agree with Mr. Spencer.  However, perhaps we need an additional
interpretation ahead of this one.  Is inclusion a "volatile" operation?

Hmm.  In fact, if a program is being interpreted instead of compiled,
the program itself can be responsible for its include files being
changed between two successive inclusions.  Now maybe C will finally
replace LISP.  :-) :-)

-- 
Norman Diamond, Sony Corp. (diamond%ws.sony.junet@uunet.uu.net seems to work)
  Should the preceding opinions be caught or     |  James Bond asked his
  killed, the sender will disavow all knowledge  |  ATT rep for a source
  of their activities or whereabouts.            |  licence to "kill".