[vox-tech] global variables in C

Jeff Newmiller vox-tech@lists.lugod.org
Fri, 20 Sep 2002 12:56:46 -0700 (PDT)


On Fri, 20 Sep 2002, Bill Kendrick wrote:

> 
> On Fri, Sep 20, 2002 at 10:34:51AM -0700, Peter Jay Salzman wrote:
> > 
> > 1. name clashing
> > 2. readability
> 
> These are good reasons.
> 
> I'm pretty bad about using globals all over the place, though.
> 
> My main reason, however, _is_ for readability.
> 
> In _most_ cases, the functions I'm calling need to do things to,
> or refer to, the same variables over and over again.

In an OO approach, this is when you start coupling those variables
together as various objects... kinds of "contexts" in which you work with
certain data.

> As an example, in my games I open the SDL window surface and name it
> "screen".
> 
> 
> Rather than having to pass "screen" around to ALL of the functions
> (first retrieving it from my "setup()" function), I prefer to keep it
> global.
> 
> Everyone uses it, it's simpler for me to just leave it 'out there'
> for them to use.  Sure, _some_ functions won't use it, but it's
> a lot less cluttery to do something like:
> 
> 
>   draw_spaceship();
> 
>   draw_aliens();
> 
> 
> Than it is:
> 
> 
>   draw_spaceship(screen, spaceship_x, spaceship_y, spaceship_dir,
>                  spaceship_color);
> 
>   draw_aliens(screen, aliens_array, NUM_ALIENS);
> 
> 
> It's not like this 'abstraction' of the functions benefits me.

Another way to accomplish this same simplification is to work within the
appropriate context:

  aliens_draw( &alienslist, screen);
  spaceship_draw( &spaceship, screen);

This is a compromise between your "global context" approach and the "no
context" approach you criticize.

> I'll rarely, if ever, call "draw_spaceship()" and tell it to draw
> the spaceship on some OTHER surface, or at some OTHER X/Y coordinate
> than where the spaceship actually _is_! ;)

I don't expect you to draw it in the wrong position, but do you mean to 
say you never use offscreen bitmaps?

> IANACG (I am not a C guru), YMMV (your milage may vary),
> UAYOR (use at your own risk), GATAA (geez, aren't these acronyms annoying?)
> 
> ;)
> 
> -bill!

For small programs, a limited number of global variables can be a good
thing.  Global variables become bad when you begin to reach a certain
level of complexity, and learning how to get around them without building
functions that use stupidly long lists of arguments is where skill in
software engineering starts to show its value.  The steps between here and
there are small, logical, and compelling... but there are a lot of steps,
so you will probably only make them when you see their value.

---------------------------------------------------------------------------
Jeff Newmiller                        The     .....       .....  Go Live...
DCN:<jdnewmil@dcn.davis.ca.us>        Basics: ##.#.       ##.#.  Live Go...
                                      Live:   OO#.. Dead: OO#..  Playing
Research Engineer (Solar/Batteries            O.O#.       #.O#.  with
/Software/Embedded Controllers)               .OO#.       .OO#.  rocks...2k
---------------------------------------------------------------------------