TITLE: Globals and static variables

[unknown author 1]

>>: Now, I need to declare some global variables (about 30 of them) which
>>: need to be used in sub-1, sub-2, and sub-3.  My question is WHERE shoud
>

[unknown author 2]

>If you're writing a real C++ program with a genuine object-oriented
>design, anything you'd need a global variable for should be able to be
>done with a static data member of a class or classes accessible to the
>other classes in the program.  [...]

[Jamshid Afshar (jamshid@emx.cc.utexas.edu), 14 Oct 93]

The phrase "object-oriented" is being used nowadays like it's going
out of style.  (hmmm ;-) This is the second reply I've seen that
says "global variables are bad, use static data members instead".  I
agree global variables should be avoided, and static data members are
to be preferred because they do not pollute the global name space, but
why are static data members any more "object-oriented" than globals?
Why exactly are they so much better?

Lippman's _C++ Primer 2nd Ed_ 3.5 p120 (btw, I hate to think some C++
programmers avoid this book because they think they don't need a
"primer") lists the following problems related to functions using a
global variable:

   o The functions that utilize the global variable depend on the
     existence and type of that global variable, making the reuse of
     that function in a different context much more difficult.

   o If the program must be modified, global dependencies increase the
     likelihood of introducing bugs.  Moreover, introducing local
     changes require an understanding of the entire program.

   o If a global variable gets an incorrect value, the entire program
     must be searched to determine where the error occurs; there is
     no localization.

   o Recursion is more difficult to get right when the function makes
     use of a global variable.

Let me add as a corollary to the last item that globals hinder
reentrancy, which is becoming very important as all major os's are
starting to support threads.

Using a static data member instead of a global does NOT help solve ANY
of the above problems.  I even loosely use the term "global variables"
to include static data members.

Let's not fall into the trap of proclaiming that doing something the
C++ or object-oriented "way" solves the entire problem.  These
gratuitous claims about C++, not its complexity or lack of garbage
collection, are what causes me the most amount of worry about C++'s
future.  If C++ is viewed 5 years from now as a big mistake, it won't
be because it was a bad choice or because of the language itself, but
because of unfounded promises and hype about what it can do.

[Fergus James HENDERSON (fjh@munta.cs.mu.OZ.AU)]

I think you're wrong about this [the use of static data members not helping
to solve any of the above problems]. In particular use of private static
data members improves localization (your third point). 

[Mark Terribile (mat@mole-end.matawan.nj.us)]

All but this last are instances of _coupling_.  If the static variable
is private, it _can't_ be coupled to things outside of the class scope
and friends.
If the static variable is public, the coupling is possible, but visible.

[Jamshid Afshar (jamshid@emx.cc.utexas.edu)]

Yes, you are both right that making static data members private (and
even protected) greatly localizes and controls their access.  In that
sense they are a major improvement over global variables, but I don't
think it's fair to compare them to global variables.

The much more worthy C analogues to C++'s private static data members
are file-scope `static' variables.  Private static data members do
have an advantage over file-scope `static's in that they can be
accessed in multiple modules (on a more flexible and logical
function-by-function basis) while still keeping the extent of their
access very controlled and known.  This is an improvement but it
certainly doesn't lead to revolutionary different programming
possibilities over C (like C++'s virtual functions, multiple
inheritance, or templates).

[Fergus James HENDERSON (fjh@munta.cs.mu.OZ.AU)]

If a private static data member gets an incorrect value, you only have to
search through that class to find out where the error occurs. [...]

[Jamshid Afshar (jamshid@emx.cc.utexas.edu)]

Yes, but remember file-scope `static's offers this advantage, too.
The only advantage of non-public static data members over file-scope
statics is their ability to be accessed in multiple modules (usually
this is only relevant if the class has `friend's since a class's member
functions are often defined in one .cc file).

[Fergus James HENDERSON (fjh@munta.cs.mu.OZ.AU)]

While reentrancy is required in some circumstances, in other circumstances 
static or global variables may have an important efficiency advantage
over the use of references or pointers to shared data. By reducing the
need for explicit parameter passing, they may reduce the overall complexity
of the program. In these cases I think it's best to use (private) static
data members.

[Jamshid Afshar (jamshid@emx.cc.utexas.edu)]

I can't think of many situations where I would recommend the use of
"static life-time" (eg, globals, fie-scope statics, static data
members) variables.  I've encountered way too many situations where
the specs for a piece of software changed because users (who we were
guaranteed would *never* want to) decided they wanted to work on
multiple databases at the same time, wanted to display data to
different (and differently sized) windows/monitors/screens at the same
time, etc.