From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-03-12 15:17:47
At 06:01 PM 3/11/2002, dylan_nicholson wrote:
>--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
>> At 08:50 PM 3/10/2002, dylan_nicholson wrote:
>> Many of those O/S properties are constants, not variables, so don't
>> the same set of problems. The existence of a file (and even
>whether it is
>> a file or directory, since that may change unexpectedly too) is in
>> global variable; that's why error handling is so important in this
>> other I/O related libraries.
>Currently logged-in user is not constant under most modern OS's, nor
>is active window, nor is the environment, nor is current
>And why is the existence (or indeed the contents) of a file an "ok"
>global variable to access/modify, but current directory not?
None of those are "OK". They are all dangerous in proportion to the
likelihood that they change unexpectedly.
> As it it I agree that 90%, maybe even
>95% of global variable uses are best avoided, and all global data
>should be used with extreme caution. But I honestly can't believe
>too many people have seriously thought about what *no global data at
It isn't all global data. Constants are harmless. Global variables are
>> And the global state issues are well-know; Boost just added a new
>> to help deal with that problem.
>Which library is that?
Daryle Walker's I/O state saving library.
But my point is, let's say my application
>uses several 'global' resources:
>* files in the current directory
>* standard output device
>* standard input device
>* standard error device
>* a log file
>* environment variables
>* an event dispatching table that keeps track of objects that recieve
>* the current user id
>* configuration files specifying locations for various resources
>* current user preferences for the font/colour/size of GUI widgets
>Are you suggesting that *ALL* this information should be passed to
>every function that might ever need it (including obviously functions
>that don't need it directly, but make use of others that do).
Of course not. Provide a function that returns a constant value. Or save
and restore the state involved - that amounts to turning a variable into a
constant. Or write code that assumes the global variable changes value
between accesses. Sometimes it is harder, sometimes easier.
But the real issue isn't global variables in general, it is setting/getting
current working directory.
So far, the little bit of programming I've done using initial_directory()
rather than current_directory() has gone smoothly. That's the proof of the
pudding. Is the code better or worse because it doesn't set/get current
directory. So far, it seems easier to write, to read, and more
robust. It was easier because it didn't require keeping a mental image of
where in the directory tree "current" was. The variable names were more
indicative. But far more test cases are needed.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk