Path: utzoo!attcan!uunet!husc6!bloom-beacon!mit-eddie!mit-amt!mit-caf!vlcek From: vlcek@mit-caf.UUCP (Jim Vlcek) Newsgroups: comp.lang.c Subject: Initialization in #include files Message-ID: <1021@mit-caf.UUCP> Date: 5 Jun 88 22:50:06 GMT References: <28400001@ntvax> <6104@sigi.Colorado.EDU> <2955@ihlpe.ATT.COM> <7948@brl-smoke.ARPA> <851@.UUCP> Reply-To: vlcek@mit-caf.UUCP (Jim Vlcek) Organization: Microsystems Technology Laboratory, MIT Lines: 64 In article <851@.UUCP* peter@ficc.UUCP (Peter da Silva) writes: *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. If one changes/deletes a variable in an #include file, one must comb through every source file using that #include file and change/delete every reference to that variable. This chore is quite likely to dwarf the task of changing the (smaller number of) declarations of the changed variable in the source modules which ``own'' the changed/deleted variable. It seems to me that #include files are intended to contain only the most generic of information: typedefs, function prototypes and macros, generic #defines, and external variable declarations. The ideal #include file should give everything and ask nothing in return; the hacks to allow initialization contain a quiet demand that I, somewhere in my application, define a necessary constant. It's also conceivable that the global variables specified in an #include file may be ``owned'' by separate source modules, in which case different #defines have to be used for each global variable, etc. I'm frankly perplexed why people will perform such gymnastics to put their initializations into #include files. I only want to have to look at the #include files when generating code, not when checking it. I'd much rather have my initializations in the source module itself, rather than have to try and figure out which #include file it's in, and then hunt it down there. -- Jim Vlcek vlcek@caf.mit.edu !{ihnp4,harvard,seismo,rutgers}!mit-eddie!mit-caf!vlcek