Re: [boost] Filesystem Review

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-09-23 13:52:01

At 02:09 PM 9/21/2002, Jeff Garland wrote:

 >* Why does path::branch return a path instead of a string?  This seems a
 > bit uneven since all the other 'query' functions of path return a 
string.

If a function returns a single element from the conceptual model sequence, 
the return type is std::string.

But if the function returns multiple elements, then the return type is 
path.

Once Thomas Witt's suggestions get incorporated, there will be other 
functions that return paths (relative(), for example, although the name may 
change) and then branch() won't be so lonely:-)

 >* It is inconvenient that a trailing '/' is not allowed on directory path 

 >  construction of POSIX paths.  This does not seem like 'invalid path
 >  syntax'.
 >  As an example, if I type 'ls /home/foo' or ls '/home/foo/' (assuming
 >  /home/foo is a directory) the result is the listing of the directory
 >  contents.  If /home/foo is a file then I get an error.

Maybe disallowing / at the end is being too picky. It doesn't really hurt 
anything. I don't have a strong feeling one way or the other.

 >* The 'Representation Example' link in the path documentation is busted
 >  everywhere.

Hum. I don't see anything wrong. It works with Netscape 3.x and IE 5.x. 
What browser are you using? Maybe spaces in bookmarks aren't supported by 
all browsers.

 >* I haven't followed the make_absolute discussion in detail, but it seems 

 >  like this is headed in the right direction.

Yes.

 >* I have this feeling that path could eventually become its own piece of
 >  infrastructure that expands beyond fs as it is currently formulated.
 >  That is, is there any reason why 'http://www.xyz.abc/foobar.html' isn't 

 >  a path?  I know we are focused on a narrower scope at the moment, but I 

 >  think eventually I should be able to write the following C++:
 >
 >     path p("http://xyz.abc/foobar.html");

It would be possible to extend path to handle that.

 >     std::fstream f(p);  //open a network connection and download
 >     ...

I don't know the committee would feel about fstream being extended to do 
that, but your real point is that path has headroom to expand to other 
uses, and I agree completely on that.

Thanks for the detailed comments,

--Beman