Path: utzoo!utgpu!water!watmath!clyde!bellcore!tness7!killer!pollux!dalsqnt!uunet!nuchat!sugar!ficc!peter
From: peter@ficc.UUCP (Peter da Silva)
Newsgroups: comp.lang.c
Subject: Re: Help needed with #include problems
Message-ID: <851@.UUCP>
Date: 2 Jun 88 15:34:30 GMT
References: <28400001@ntvax> <6104@sigi.Colorado.EDU> <2955@ihlpe.ATT.COM> <7948@brl-smoke.ARPA>
Organization: SCADA
Lines: 43

In article <7948@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes:
> In article <998@mit-caf.UUCP> vlcek@mit-caf.UUCP (Jim Vlcek) writes:
> >Putting initialization data for a global variable into an
> >#include file seems to me almost an act of violence!
> 
> I don't know about violent, but it's a sure sign of source code out of
> control.

I disagree. It's a good idea to stick your declarations and initialisation
in one place. When you change a variable, or add one, or delete one, you
really need to make sure you get all the declarations. It's much more
convenient if it's all in one place.

But, do it intelligently:

---- foo.h
#ifdef FOO_C
#define GLOBAL
#define INIT(x) =x
#else
#define GLOBAL extern
#define INIT(x)
#endif

GLOBAL char *fooname INIT("foo");
GLOBAL char *footype INIT("program");

#undef GLOBAL
#undef INIT
----

And then:

---- foo.c
#define FOO_C

#include "this.h"
#include "that.h"
#include "foo.h"
#include "the_other.h"
-- 
-- Peter da Silva, Ferranti International Controls Corporation.
-- Phone: 713-274-5180. Remote UUCP: uunet!nuchat!sugar!peter.