* Robert Crandal:
Really, I can remove the "static" definition and my global variable will
still "exist" for the duration of my program??
Yes.
BTW, I know it's usually a bad idea to use global variables, but my
applications always seem to require a collection of "state" variables that
need to exist for the entire duration of my GUI program. In your opinion,
what's a good technique for managing a collection of state variables that
might need to be accessed at any time by another C++ file module??
Start by analyzing the data flows. What piece of the system requires exactly
what information to do its work, and where does it get it from? Draw connecting
arrows representing the data flows and try as best you can to make sure that
absolutely every "process" has /everything/ it needs, and /not more/. To the
degree possible defer decisions as to where data is stored. Many such decisions
will be unavoidable but try. Keep very strongly in mind that a data flow diagram
does generally not map one-to-one to software (this is a main reason to avoid
data storage allocation at this point). The mapping can be intricate.
It's very very old and nowaydays it's my impression it's not much used (the
simplistic version doesn't mesh well with OO), but it will give you a more clear
idea of the requirements and how things really work in your system.
Then design things -- the mapping between data flows, processing and software
-- so as to enforce the data flow directions. This involves deciding where
data should be stored, i.e. who knows about what. Ideally that should be tied to
responsibility and needs, as in an organization of people. 'const' in C++ helps
very much. Using functions to access data instead of global variables is a more
general technique, which also helps to encapsulate things and provide hooks
where tests, other functionality etc. can be attached/inserted.
usually just create a small set of unique global variable names...if no
other
variables share the same names I don't see what can go wrong??
The general problem is that globally available read/write variables provide data
flow connections everywhere, so that any piece of the system can potentially
affect any other piece. You do not know where a change comes from, or when, or
under what conditions what values are guaranteed (if any), i.e. what causes
what. The number of possible causal connections increase as the square of the
number of distinct smallest intended-to-be-understood-on-their-own "modules",
which is unmanagable. It's like a large organization where every employee is
free to modify any of the organization's data to the best (worst) of his/her
ability and perceived local needs. Instead, such access should be tied to what
each employee is responsible for and actually needs.
Good old Edsger Dijkstra touched on this in his classic paper "GOTO considered
harmful", which is available as an "ACM classic" (free).
The data flow spaghetti is the data side of things analog to goto based control
flow spaghetti, just a slightly more indirect way of establishing catastrophic
causal connections.
Cheers & hth.,
- Alf
