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

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-03-14 09:51:00

At 04:45 PM 3/12/2002, dylan_nicholson wrote:

 >--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:

 >> 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?

Because that's the library I'm working on.  If you look at standard library 
components ordered chronologically by date of invention, early ones (mostly 
C, a few of the early C++ libraries) used unfortunate global state.  As 
time passed, the awareness of the problem increased, and newer libraries 
almost never retain global state variables, and are thus much much safer.

 >> ...
 >>
 >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.

Because it is better to begin without relying on a less safe 
practice.  Then, if it appears it really is necessary, provide it in some 
ugly way that discourages use and/or alerts potential users that there is a 
problem.  For example, the nothrow version of 
boost::filesystem::remove().  Wrapping an unsafe practice in a 
hard-to-misuse class is sometimes a good approach, too.

 >>... 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.

Thanks. That is the kind of example we need.  If it is the only example 
anyone can come up with, we can provide a version of system() which takes 
the directory as an argument.  If the need is more commonplace, we can 
provide a forwarding class which pushes/pops the current directory.

Questions about your example above:

What is the expectation for portability if the O/S has only a flat (single 
directory) file system?

What is the expectation for portability if the O/S supports hierarchical 
directories, but has no concept of "current directory"?

--Beman