From: dylan_nicholson (dylan_nicholson_at_[hidden])
Date: 2002-03-14 16:50:20
--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> 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
> >> 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.
But the library you're working on *does* allow you to determine the
existence/properties of a file. That is actually far more likely to
change "unexpectedly" than the current directory - at least the
current directory can't be changed by anything else other than the
> Because it is better to begin without relying on a less safe
> practice. Then, if it appears it really is necessary, provide it
> 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.
Another good example - remove changes "global data" - ie the
existence of a file.
> >Indeed. Just yesterday I wrote a simple utility using nothing but
> >standard C++ and a few filesystem calls. And guess what - it
> >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
> anyone can come up with, we can provide a version of system() which
> the directory as an argument. If the need is more commonplace, we
> provide a forwarding class which pushes/pops the current directory.
I like the push/pop idea. But I gave an example earlier (using
Win32's GetOpenFileName) where you need to determine what the current
directory has been changed to by a library call.
> Questions about your example above:
> What is the expectation for portability if the O/S has only a flat
> directory) file system?
Just the same as if the O/S had no filesystem :o)
> What is the expectation for portability if the O/S supports
> directories, but has no concept of "current directory"?
Any OS-interfacing library has essentially an platform-dependent
implementation. If such a platform really did exist then even
fstream::open/fopen etc would need a method of telling the OS how to
open an incompletely specified filename, meaning the standard C
runtime library would probably have to maintain the current
directory. But I think you're genuinely clutching at straws here - I
would be intrigued indeed if you really know of such an OS.
It kinda seems that from other posts on this subject you are somewhat
alone in wanting to keep the current directory away from the
programmer's reach - I understand your concerns but in the end the
library has to be useful in the "real world" as it were.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk