Mail Archives: djgpp/2000/02/17/22:24:09
"William J. Urban II" wrote:
> Hello all,
> Well I am in a C++ class and also teaching myself some simple 2d game
> writing with allegro. Now, in class we learned about Global variables and
> how we should use them sparingly. My question is why?
In a large program there can be a significant stack of functions which call each
other. For example, function A calls function B which calls function C and so
on (say) down to function Z.
Once the program has been established, it becomes obvious that a new bit of
information which is needed in function Z is actually available in function A.
So how do we get the data from A to Z?
Arguably, the *best* solution is to modify functions B through Z to accept a new
parameter. This gives a clean interface.
But, wait a minute, functions B through Z are also called from many other
places,
so they too will have to donate the extra argument or the compiler will
complain.
So, since it is Friday afternoon when you are doing this change, the quick-fix
is to
copy the data into a global variable (in function A) then pick it up in function
Z.
Everything works fine and dandy: you don't understand the hassle that everyone
talks
about with global variables.
Some time later you find out that function M wants to call function N twice, the
first
time as normal and the second time with a different piece of information which
is
stored in the global.
So function M ends up creating a temporary of the same type as the global,
copying the
global there, overwriting the global, calling function N then copying the
temporary back
into the global. Phew, gotta stack up the global, change it then proceed then
undo the
damage.
And then you find that under some circumstances a lower-down function does (say)
a
longjmp and by-passes the undoing stage...
And then the mire of globals becomes visible.
Trust your teacher: in a big project globals can be deadly! Unless rigorously
managed, they
can turn and gobble you up! :-)
I teach my delegates a few rules regarding globals:
1) don't create any
2) If you have to, tomorrow or next week is fine
3) Put your name and the date beside the global (in a comment) so that the
guilty party can be identified later and fired.
4) Use "static" as a default until the global's scope widens
5) Ensure that each global has a loooooong unambiguous name (no globals
called "i", "j" or "k" else you gotta check all "for" loops)
HTH
Mungo
P.S> I'm ignoring the "X-windows" idea of a structure pointer and a bit
mask flag to help when adding new information.
--
Mungo Henning - it's a daft name but it goes with the face...
mungoh AT bigfoot DOT com http://www.itacs.strath.ac.uk/
I speak for me, not my employer.
- Raw text -