Initialization in #include files

Jim Vlcek vlcek at mit-caf.UUCP
Mon Jun 6 08:50:06 AEST 1988


In article <851 at .UUCP* peter at 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 at caf.mit.edu
!{ihnp4,harvard,seismo,rutgers}!mit-eddie!mit-caf!vlcek



More information about the Comp.lang.c mailing list