Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!nic.MR.NET!nic.stolaf.edu!news From: hannum@haydn.psu.edu (Charles Hannum) Newsgroups: comp.lang.c Subject: Re: extern Message-ID: <1990Jul5.044045.1534@acc.stolaf.edu> Date: 5 Jul 90 04:40:45 GMT References: <111254@linus.mitre.org> <910@bjcong.bj.co.uk> <277@taumet.com> <16994@haddock.ima.isc.com> Sender: news@acc.stolaf.edu Organization: The Pennsylvania State University Public NeXT Laboratory Lines: 37 In-Reply-To: karl@haddock.ima.isc.com's message of 30 Jun 90 18:56:24 GMT In article <16994@haddock.ima.isc.com> karl@haddock.ima.isc.com (Karl Heuer) writes: In article <277@taumet.com> steve@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. Speaking of which, why didn't ANSI specify that initializers on externs should be ignored? This would be really keen for the former type of definitions. "... 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). -- Virtually, Charles Martin Hannum "Those who say a thing cannot be done should Please send mail to: under no circumstances stand in the way of hannum@schubert.psu.edu he who is doing it." - a misquote