×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
Ken Sims wrote:
...
Personally I define all such "resetable" variables as global
variables. Most of my service programs have an "open" procedure
(which calls the "reset" procedure), a "reset" procedure, and a
"close" procedure.
If the module is acting as an "abstract data type", where all the
procedures work with the same static data, it makes perfect sense to use
global variables for the data. What you describe sounds like this type
of module.
In the case where a single procedure has some static data that should be
private to the procedure, using a global variable opens up the
possibility that all the procedures in the module can mess with the
data. Physically limiting access to just that one procedure tends to
simplify maintenance. Even though you have to jump through a hoop to be
able to reset the private static data, it's a small and finite hoop.
Figuring out what will be impacted if you change the nature of your
should-be-private-but-is-public static variable can be a large and
infinite hoop.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact
[javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
