Path: utzoo!dptcdc!jarvis.csri.toronto.edu!mailrus!purdue!decwrl!labrea!rutgers!bellcore!faline!thumper!ulysses!andante!alice!ark
From: ark@alice.UUCP (Andrew Koenig)
Newsgroups: comp.lang.c
Subject: Re: On global variables
Message-ID: <9215@alice.UUCP>
Date: 18 Apr 89 16:42:17 GMT
References: <826@twwells.uucp>
Organization: AT&T Bell Laboratories, Liberty Corner NJ
Lines: 34

In article <826@twwells.uucp>, bill@twwells.uucp (T. William Wells) writes:

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

Suppose you have some kind of transaction processing system with
a menu-oriented user interface.  The state of the screen is presumably
one of these `state variables' you mention.

Now someone comes along and tells you to rework your system to
allow split screens -- that is, multiple transactions on one
physical screen.  Presto!  You have just been forced to rework
your design to distinguish between logical and physical screens
and to know which logical screen you're working on, and how the
state of the logical screen relates to the state of other things
in your program you must now replicate, and so on.

Thus even in `obvious' cases like this, it may sometimes pay off
to put things that look at first as if they should be global
into a structure of some kind whose address is passed around
to every function that needs those entities.

Of course, this is a pain; hence many people don't do it.
It would be nice if C had some kind of facility for passing
stuff of this kind around implicitly so you didn't have to
write an extra argument for every function and every reference
to `global' data.

Now you know one of the reasons C++ works the way it does.
-- 
				--Andrew Koenig
				  ark@europa.att.com