This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Question--EXTERN: good or bad (or neutral)?
- To: Elena Zannoni <ezannoni at cygnus dot com>, gdb at sources dot redhat dot com
- Subject: Re: Question--EXTERN: good or bad (or neutral)?
- From: Kevin Buettner <kevinb at cygnus dot com>
- Date: Wed, 1 Aug 2001 15:58:02 -0700
- References: <15208.34467.908215.907865@krustylu.cygnus.com>
On Aug 1, 6:45pm, Elena Zannoni wrote:
> How do people feel about this thing in buildsym.h?
>
> /* [...]
> Variables declared in this file can be defined by #define-ing the
> name EXTERN to null. It is used to declare variables that are
> normally extern, but which get defined in a single module using
> this technique. */
>
> #ifndef EXTERN
> #define EXTERN extern
> #endif
>
>
> buildsym.c does this:
>
>
> /* Ask buildsym.h to define the vars it normally declares `extern'. */
> #define EXTERN
> /**/
> #include "buildsym.h" /* Our own declarations */
> #undef EXTERN
>
>
> while the other files that need those variables, simply include
> buildsym.h w/o redefining EXTERN.
>
>
> Same thing occurs with stabsread.h and stabsread.c.
>
>
> Is there any reason for not moving the definitions into the .c files?
If you *really* need lots of global variables, the EXTERN trickery
could be a good thing because it could make maintenance easier. I.e,
when you want to change one of the types, it would only need to be
changed in one spot and you don't have diverging comments, etc.
However, I think we're taking the viewpoint these days that macro
trickery like the above is bad style. In addition, we shouldn't be
defining that many global variables anyway. In fact, we *should* be
attempting to eliminate as many of these globals as we can. So, I see
nothing wrong with making these globals more painful to use and
maintain. That way, when one of us wants to change one of these,
perhaps we'll take a look at the code and find a way to do the same
job without the global.
(So, yes, I think moving the definitions into a .c file is a good idea.)
Kevin