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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-03-14 10:05:42

From: "Beman Dawes" <bdawes_at_[hidden]>
> 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.

The current directory is not related in any way to a standard library
component. It is a fact of life (fopen("test.txt", "r") - where is
test.txt?) You can ignore it but it will continue to exist; for instance, a
third-party library can change it and you'll have no recourse.

Trying to "protect" programmers from its existence is misguided. Instead,
every function that manipulates a path and is affected by the current
directory should have a variant that takes a "logically current directory"
as a parameter, i.e. expand this path as if the current directory were
/foo/bar.

An "initial directory" concept is useful to denote the directory of the
executable file; programs often need to find their associated data files.