Xref: utzoo comp.lang.c:23179 comp.lang.c++:5180 gnu.g++:464
Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!ucsd!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!deimos.cis.ksu.edu!atanasoff!hascall
From: hascall@atanasoff.cs.iastate.edu (John Hascall)
Newsgroups: comp.lang.c,comp.lang.c++,gnu.g++
Subject: Re: A solution to the multiple inclusion problem
Keywords: #include c
Message-ID: <1659@atanasoff.cs.iastate.edu>
Date: 24 Oct 89 00:24:04 GMT
References: <14240@well.UUCP> <1989Oct23.191634.6345@cs.rochester.edu>
Reply-To: hascall@atanasoff.UUCP (John Hascall)
Distribution: comp
Organization: Iowa State Univ. Computation Center
Lines: 28

In some article with a silly huge id#, Lawrence Crowl writes:
}In article <14240@well.UUCP> nagle@well.UUCP (John Nagle) notes three
}solutions to the multiple file inclusion problem:
 
}(2) Modifying the semantics of #include to only include a file once.  This is
}    incompatible with the current definition of #include.
 
}  [yet another scheme...]

    Since the impending ANSI standard requires that including a file more
    than once have exactly the same effect as including it once...why can't
    a compiler just ignore #includes for files it has already #included???
    (at least for the "standard" includes)
    
    Any comments from the ANSI mavens?


    I know some people use stuff like:

 main.c:                              subr.c:
    #define MAINDEF 1                    #define MAINDEF 0
    #include "vars.h"                    #include "vars.h"
    main()                               subrtn()
    { ...                                { ...

    but, does anyone do this thing in the *same* file??

John Hascall