Re: [boost] Re: Design for a file system library

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
 >present
 >> 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
 >effect a
 >> global variable; that's why error handling is so important in this
 >and
 >> 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
 >directory...etc. etc.
 >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
 >all* implies.

It isn't all global data.  Constants are harmless.  Global variables are 
the problem.

 >> And the global state issues are well-know; Boost just added a new
 >library
 >> 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
 >certain events
 >* the current user id
 >* configuration files specifying locations for various resources
 >* current user preferences for the font/colour/size of GUI widgets
 >etc. etc.
 >
 >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.

--Beman