On Sun, Jan 24, 2010 at 2:57 PM, anonymous <aim0shei_AT_lavabit.com> wrote:
> Where programs should store their options? Sometimes it is said that
> global variables are bad, but what is better? Some huge structure
> storing all options? Of course, they can be divided into many
> structures or they can be passed on a stack instead of passing pointer
> to structure but it is not effective.
>
> Here is citation from TAOUP
> (http://www.catb.org/esr/writings/taoup/html/ch04s06.html):
> "[...]"
>
> So lots of global variables are bad, but saving them in a local
> structure is bad too? Is there any other other solution?
Unless you do craziness like allocate a giant datastructure at the
start of your app and pass it around as a param everything, you'll
always need -something- to be global. There's nothing wrong with
having 'int rflag;' at the top of your program. Globals only become a
problem when every subsection of your program is using them to store
information that really should be private.
Settings information I've always found necessary to store in globals,
even if it is just a single giant struct Options {...} options. Trying
to do it any other way (IoC comes to mind) has some benefits but makes
your program complexity shoot up; you might end up spending more time
designing the interactions of your components than actually making
them work.
If you're working in C you're kinda stuck with information leakage
that.. .but you can just use prefixes to make yourself namespaces and
you'll be dandy. If you're working in another language that supports
modules inherently you can just use that.
-Nick
Received on Mon Jan 25 2010 - 12:14:36 UTC
This archive was generated by hypermail 2.2.0 : Mon Jan 25 2010 - 12:24:02 UTC