RE: [boost] Filesystem Review

From: Jeff Garland (jeff_at_[hidden])
Date: 2002-09-23 14:46:42

> 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:-)

Ok.
 
>  >* 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.

Ok, then I would prefer to allow it because otherwise a program 
taking human input has to be certain to strip this off to get the 
'expected behavior'.  For example if you write a program run from
a command line that takes a directory path as an argument and happen 
to use the bash autocomplete feature (which automatically tacks on a /
to directory names) if your program doesn't strip the / it gets
an exception.  As you can see, this has happened to me :-)

>  >* 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.

Konqueror on Linux.  And, yes I confirmed it is the space that is the problem.

>  >* 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.

Yes, in retrospect it probably should be something like std::http_stream,
which is yet another sorely needed C++ library given the role of the
internet these days.  Of course we need still need a socket library 
first....

Jeff