Initialization in #include files
Peter da Silva
peter at ficc.UUCP
Fri Jul 1 10:39:46 AEST 1988
In article <1021 at mit-caf.UUCP>, vlcek at mit-caf.UUCP (Jim Vlcek) writes:
> In article <851 at .UUCP* peter at ficc.UUCP (Peter da Silva) writes:
> *#ifdef FOO_C
> *#define GLOBAL
> *#define INIT(x) =x
> *#else
> *#define GLOBAL extern
> *#define INIT(x)
> *#endif
... and so on...
> 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.
If one deletes a global variable, one must comb through every source
file that might be using that variable anyway. If one changes a variable,
that's still true. Whether or not that variable is declared in an include
file (for example, _ctype in ctype.h) or not. The same is true when you
change an element of a structure declared in an include file.
I don't understand this objection at all.
> 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.
Since the external variable is declared in an include file, why not
initialise it there as well? Keeps everything nice and handy.
> 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.
Since the include file is part of your application, what's the big deal?
If it's not, then presumably the author of the library you are using
provided the necessary #define in some standard place (for example,
in ctype.c).
> 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.
Right. I generally have a source file foo.c, and an accompanying include
file foo.h. The source file has FOO_C defined at the beginning of the module.
> 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.
But the include file it's in is obvious. And if I change an element in an
initialised structure from char to long, I only want to have to change it
in one place.
Anyway, I find the technique useful. Other people might, too. With the
slightest bit of discipline you need never fear inconsistent structure
definitions again!
--
-- `-_-' Peter (have you hugged your wolf today) da Silva.
-- U Ferranti International Controls Corporation.
-- Phone: 713-274-5180. CI$: 70216,1076. ICBM: 29 37 N / 95 36 W.
-- UUCP: {uunet,academ!uhnix1,bellcore!tness1}!sugar!ficc!peter.
More information about the Comp.lang.c
mailing list