From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-03-20 12:28:49
At 11:14 AM 3/20/2002, Peter Dimov wrote:
>From: "Beman Dawes" <bdawes_at_[hidden]>
>> Comments would be appreciated. And of course, thanks to everyone who
>> provided comments leading to the current design.
>I think that is_file should not map to !is_directory, leaving the door
>for non-file, non-directory paths.
I'm open on this. Some people seem to view everything (devices, sockets,
etc.) as a file (even directories). Others view everything except
directories as files (again, even devices, sockets, etc.)
Maybe it would be better to remove is_file() entirely. In looking at the
code I've written so far, it seems like I always write !is_directory().
>How are relative paths handled?
It is up to the application. See next question.
>What is the purpose of initial_directory() if it doesn't affect relative
Let's say a user provides a relative path to a directory your program is
supposed to operate on. (Presumably your program can tell this from one of
the filesystem/path.hpp functions.)
(Assume you told the user relative paths were relative to the current
working directory at time of program invocation. Otherwise the issue of
current or initial directory wouldn't come up because other scenarios know
what the relative path is relative to.)
Now you could just pass that relative path to some boost::filesystem
function, and it might work just fine. But it might not work exactly as
expected. Some other 3rd party or native system library function may have
changed the current working directory unexpectedly.
So code something like this is a lot safer:
int main( int argc, char * argv
initial_directory(); // lock down before calling other functions
if ( user provided a relative path )
dir_path = compose( initial_directory(), user provided path );
dir_path = user provided path;
At that point dir_path is known to be absolute, and can be used for the
life of the program without worrying if the current working directory is
changed by library calls.
>basic_directory_iterator probably doesn't need a destructor.
Depends on how the internals are implemented, doesn't it? If the rep type
is opaque and non-trivial (as in the current imp) then a destructor is
needed, for example.
>basic_directory_entry::path() says 'returns compose(...)' but there is no
>compose function, or path manipulation functions in general; are they
>supposed to be in a separate library?
Yes, the lexical path manipulation functions (compose is just a placeholder
name) will be in boost/filesystem/path.hpp. At least that is the current
Thanks for the comments,
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk