Re: Design for a file system library

From: dylan_nicholson (dylan_nicholson_at_[hidden])
Date: 2002-03-12 16:45:26

--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> At 06:01 PM 3/11/2002, dylan_nicholson wrote:
>  >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.
> 
Then why are you singling out current directory as something 
programmers shouldn't be able to access/change easily?

>  >> 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 how does that relate to cout/cerr/cin being global?  The issue of 
state permanence applies to all streams, even ones that you do 
carefully pass around everywhere as needed.

>  >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.
> 
Ok then we are in complete agreement.  But you haven't explained 
why "current directory" shouldn't be the sort of global data that 
needs controlled/careful access as opposed to no access.

> 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.
> 
Indeed.  Just yesterday I wrote a simple utility using nothing but 
standard C++ and a few filesystem calls.  And guess what - it needed 
to change and restore the working directory because it executed 
another application (using system), which had to be run in a 
particular directory to work correctly.

Dylan