Boost logo

Boost :

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


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