Boost logo

Boost :

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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk