Initialization in #include files

[Leo de Wit]

In article <1002 at ficc.UUCP> peter at ficc.UUCP (Peter da Silva) writes:
>In article <1021 at mit-caf.UUCP>, vlcek at mit-caf.UUCP (Jim Vlcek) writes:
 [stuff deleted]...
>> 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.

I can only agree. Header files are for declarations, source files for
definitions.

>Since the external variable is declared in an include file, why not
>initialise it there as well? Keeps everything nice and handy.

Why not put the functions there as well? What makes functions different
from variables with respect to declaration and definition? In this manner
you can do everything with only header files. Boy, that will make things
really clear 8-).

>> 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.

My idea. The header file is the (outgoing) interface of a source module
to the outside world.

>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).

The big deal, as you put it, is that you use header files for purposes
they weren't meant to deal with. I sometimes see beginning C programmers
put functions in .h files, then include those .h files in their
programs to have the functions available. If you really need to do this
(but I can hardly think of a good reason) use a separate .c file to put
the stuff in.

>> 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.

You still have to adjust each usage of that element.

>Anyway, I find the technique useful. Other people might, too. With the
>slightest bit of discipline you need never fear inconsistent structure
>definitions again!

Sorry to disagree with you Peter, but I don't share your opinion. The
whole idea is like a magic trick. And if you're out for tricks, you
could just as well put all source in one file, distinguishing between
modules with an ifdef surrouding each module in the file 8-) (smiley
added to ensure that people will not take this as a serious
possibility).

You need never fear inconsistent structure definitions with header
files, as you should typedef them once in the header file, then use
that type throughout the code. As for difference in types for
declaration and definition, every decent compiler should (at least)
complain.

       Leo.