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
> 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.
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk