A solution to the multiple inclusion problem

[Norman Diamond]

Someone:

>>>      I propose a solution via compiler optimization.

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

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

In article <1989Oct25.164145.29980 at utzoo.uucp> henry at 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 at 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".