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.