From: dylan_nicholson (dylan_nicholson_at_[hidden])
Date: 2002-03-11 18:01:59
--- 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?
> It isn't just me that is saying "global variables considered
> is the whole software engineering establishment. Wulf and Shaw's
> that name is considered one of the great papers in computer
I can't seem to find that paper anywhere online, although I'm very
much interested in reading it. 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
all* implies. Even functional languages have implied global data
(for instance calling 'print' prints to some implied globally
available output device).
> >Just like typos and cliches :o) I'm not sure what you define as a
> >Global variable. Global data is essential in most large scale
> >applications and libraries, provided it's managed sensibly (ie no
> >direct access). If you literally had to pass all the information
> >ever needed around as function parameters I would give up
> >Btw have you ever used cin, cout or cerr?
> And the global state issues are well-know; Boost just added a new
> to help deal with that problem.
Which library is that? 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).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk