extern

Leo de Wit leo at ehviea.ine.philips.nl
Sun Jul 8 02:29:39 AEST 1990


In article <1990Jul5.044045.1534 at acc.stolaf.edu> hannum at haydn.psu.edu (Charles Hannum) writes:
|
|In article <16994 at haddock.ima.isc.com> karl at haddock.ima.isc.com (Karl Heuer) writes:
|
|   In article <277 at taumet.com> steve at taumet.UUCP (Stephen Clamage) writes:
|   >The usual trick is then to do something like this:
|   >	#define EXTERN extern
|
|   In rebuttal, I'd like to mention that many of us find this grotesque, and
|   prefer to use
|	   /* header.h */
|	   extern int foo[20];
|	   extern double bar;
|
|	   /* something.c */
|	   #include "header.h"
|	   int foo[20];
|	   double bar = 3.0;
|   which is also completely portable, doesn't require preprocessor games, and
|   allows the objects to have initializers (this can sometimes be done with your
|   method too, but it makes it even uglier).  Since the defining source file also
|   includes the header, you can't get them out of sync.
|
|
|Some of us also find your method grotesque, because we have to alter the
|definition in *two* places rather than one if we change it.

Apparently another mix-up of declarations (which I feel belong in
header files) and definitions (which I feel belong in source files).
If you find this grotesque, why make a difference for function
declarations/definitions? Be consequent and have the body of the
function conditionally included in the header file ...

I'd also like to know how the 'extern-trick-advocates' handle multiple
include files; each would need its own EXTERN macro (and guess what
mysterious failures happen if you misspell them in the source file).
And then I'm not even talking about nested include files.

    []
|"... preprocessor games, ..."?  It's not a game.  It's a perfectly ligitimate
|use of the C preprocessor.  If we weren't supposed to use it, it wouldn't be
|included (based C's minimalist philosophy).

Whether or not this is a perfectly legitimate use of the C preprocessor
is not the issue. I'm sure the Obfuscated C Code Contest will give us
again lots of perfectly legitimate programs, showing us how NOT to
code.

    Leo.

#define EXTERN GROTESQUE



More information about the Comp.lang.c mailing list