On global variables

[T. William Wells]

My own solution to the problem of globals is this:

State variables, ones which map fairly obviously into the current
processing state of a program subsystem, should be globals. Note this
is "should", not "may". Variables which are dependent on local context
should be function parameters. Variables which are intermediate may
be either globals or function parameters, with clarity and efficiency
(and sometimes the quirks of C) determining which. When a given
subsystem is small (e.g., a function or two), parameters should
generally be used, though there are times when globals are more
appropriate.

As an example: I tend to have to write complex systems which operate
with control structures that contains lots of data. It would be
costly to pass the address of the control structure (about 10% in
space and execution time, I often write small functions) to all the
routines in the system and wouldn't add one bit to program clarity;
what I do is have the system interface routines store the address of
the structure as a global and have each routine which needs it use it.
In this case, an obvious part of the operating state is the current
context the system is operating in, thus that current context should
be a global.

Another example of a state variable is the program parameter,
typically set at the start of the program and never changed
thereafter, or only changed on user request. Again, this often maps
directly and obviously into the current program state and thus should
be global.

---
Bill                            { uunet | novavax } !twwells!bill
(BTW, I'm may be looking for a new job sometime in the next few
months.  If you know of a good one where I can be based in South
Florida do send me e-mail.)