Path: utzoo!utgpu!water!watmath!clyde!bellcore!faline!thumper!ulysses!andante!mit-eddie!mit-amt!mit-caf!vlcek
From: vlcek@mit-caf.UUCP
Newsgroups: comp.lang.c
Subject: Re: Help needed with #include problems
Message-ID: <998@mit-caf.UUCP>
Date: 21 May 88 00:49:51 GMT
References: <28400001@ntvax> <6104@sigi.Colorado.EDU> <2955@ihlpe.ATT.COM>
Reply-To: vlcek@mit-caf.UUCP (Jim Vlcek)
Organization: Microsystems Technology Laboratory, MIT
Lines: 26
Posted: Fri May 20 20:49:51 1988

People have been asking how to take care of external variables that
must appear in #include files; namely, how does one declare them in
the one file in which they are defined?

The answer I have seen so far is to use #defines to flag to the
#include file whether the current source file contains the variable
definition or merely an external reference.

Perhaps I am missing something, but this seems to me the wrong way to
do things.  For one thing, in a large application, one might need
quite a few #defines to take care of all of the external variables,
which may be interspersed through a number of #include files.  The
target of each #define would then have to be matched with its host
#include file, which the programmer would have to inspect to find out
initialization data, etc, etc.  Good heavens!

I am under the impression that there is nothing wrong with having an
``extern'' reference *and* a variable definition in the source file,
and in fact I have done so in all of my C programming.  So my #include
files contain only ``extern'' references; I declare (and initialize)
the variable in the proper source file, somewhere after the #include
statement.  Putting initialization data for a global variable into an
#include file seems to me almost an act of violence!
-- 
Jim Vlcek
vlcek@caf.mit.edu
!{ihnp4,harvard,seismo,rutgers}!mit-eddie!mit-caf!vlcek