Re: [boost] boost/filesystem/directory.hpp attached for comment

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 
open
 >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
 >paths?

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
   string dir_path;
   if ( user provided a relative path )
     dir_path = compose( initial_directory(), user provided path );
   else
     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 
plan.

Thanks for the comments,

--Beman