Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!ubvax!lll-winken!uunet!mcvax!philmds!leo From: leo@philmds.UUCP (Leo de Wit) Newsgroups: comp.lang.c Subject: Re: Initialization in #include files Message-ID: <548@philmds.UUCP> Date: 3 Jul 88 09:55:28 GMT References: <28400001@ntvax> <6104@sigi.Colorado.EDU> <2955@ihlpe.ATT.COM> <1021@mit-caf.UUCP> <1002@ficc.UUCP> Reply-To: leo@philmds.UUCP (Leo de Wit) Organization: Philips I&E DTS Eindhoven Lines: 68 In article <1002@ficc.UUCP> peter@ficc.UUCP (Peter da Silva) writes: >In article <1021@mit-caf.UUCP>, vlcek@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.