Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/3/84; site talcott.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!godot!harvard!talcott!kendall From: kendall@talcott.UUCP (Sam Kendall) Newsgroups: net.lang.c Subject: multiple external defs (Re: Lattice/UNIX incompatibility) Message-ID: <206@talcott.UUCP> Date: Fri, 4-Jan-85 11:57:26 EST Article-I.D.: talcott.206 Posted: Fri Jan 4 11:57:26 1985 Date-Received: Sun, 6-Jan-85 00:45:13 EST References: <3220@alice.UUCP> Organization: Sociology Dept., Harvard Univ. Lines: 25 > 3. Common sense indicates that the definition of > an external variable should appear only once in the > program text, so that its type can be changed by > only altering one thing. The logical place > for such a single definition is in an include file. > However, under the restrictive definition of C, > this is impossible: the program breaks whether the > include file says "extern" or not. > > [ -- Andrew Koenig ] On the other hand, one very good programming style dictates that the declaration of an external variable, or any external name, appear in two places: once in the specification of a module (in C, roughly corresponding to a .h file) and once in the implementation of a module (in C, a .c file); and perhaps even a third time, in the documentation of the module. This duplication ensures that the specification and implementation remain compatible, since if only one changes the compiler will complain; it encourages thinking about a program as a set of modules with interfaces, rather than as a set of external variables; and, of course, this duplication properly discourages external variables by making them a pain in the butt to add (hee hee). Sam Kendall {allegra,ihnp4,ima,amd}!wjh12!kendall Delft Consulting Corp. decvax!genrad!wjh12!kendall