Mirror of the gdb mailing list
 help / color / mirror / Atom feed
* Question--EXTERN: good or bad (or neutral)?
@ 2001-08-01 15:37 Elena Zannoni
  2001-08-01 15:58 ` Kevin Buettner
       [not found] ` <3B688CCC.1040702@cygnus.com>
  0 siblings, 2 replies; 4+ messages in thread
From: Elena Zannoni @ 2001-08-01 15:37 UTC (permalink / raw)
  To: gdb

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?

Elena


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Question--EXTERN: good or bad (or neutral)?
  2001-08-01 15:37 Question--EXTERN: good or bad (or neutral)? Elena Zannoni
@ 2001-08-01 15:58 ` Kevin Buettner
  2001-08-01 18:26   ` Elena Zannoni
       [not found] ` <3B688CCC.1040702@cygnus.com>
  1 sibling, 1 reply; 4+ messages in thread
From: Kevin Buettner @ 2001-08-01 15:58 UTC (permalink / raw)
  To: Elena Zannoni, gdb

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


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Question--EXTERN: good or bad (or neutral)?
  2001-08-01 15:58 ` Kevin Buettner
@ 2001-08-01 18:26   ` Elena Zannoni
  0 siblings, 0 replies; 4+ messages in thread
From: Elena Zannoni @ 2001-08-01 18:26 UTC (permalink / raw)
  To: Kevin Buettner; +Cc: Elena Zannoni, gdb

Kevin Buettner writes:
 > On Aug 1,  6:45pm, Elena Zannoni wrote:
 > 
 > > How do people feel about this thing in buildsym.h?

 > > 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.

Yes, I haven't actually even looked at how many of these globals need
to be exported. Maybe it is the case that only a few are actually
necessary in the .h file. 

 > 
 > (So, yes, I think moving the definitions into a .c file is a good idea.)
 > 

Yeah. Lots of low hanging fruits in those files.


 > Kevin

Elena


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Question--EXTERN: good or bad (or neutral)?
       [not found] ` <3B688CCC.1040702@cygnus.com>
@ 2001-08-01 18:56   ` Elena Zannoni
  0 siblings, 0 replies; 4+ messages in thread
From: Elena Zannoni @ 2001-08-01 18:56 UTC (permalink / raw)
  To: Andrew Cagney; +Cc: Elena Zannoni, gdb

Andrew Cagney writes:
 > > How do people feel about this thing in buildsym.h?
 > 
 > 
 > I think you've just found use 438 for a partial-stab.h printout .....
 > 

No comment! :-)

 > 
 > > Is there any reason for not moving the definitions into the .c files?
 > 
 > 
 > Per Kevin's comments, it was a good idea at the time.
 > I can't think of a good reason for hanging on to it.
 > 

Yeah. I 'suspected' we all would think this way. I posted that for
amusement value, more than anything else. The stuff has been there
since October of 91.

 > 	Andrew

Elena


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2001-08-01 18:56 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-08-01 15:37 Question--EXTERN: good or bad (or neutral)? Elena Zannoni
2001-08-01 15:58 ` Kevin Buettner
2001-08-01 18:26   ` Elena Zannoni
     [not found] ` <3B688CCC.1040702@cygnus.com>
2001-08-01 18:56   ` Elena Zannoni

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox