Boost logo

Boost :

From: Glen Knowles (gknowles_at_[hidden])
Date: 2003-08-15 01:28:53

>From: David Abrahams [mailto:dave_at_[hidden]]
>>> portable_path("/foo/bar") <- throws on Windows
>> Not sure why this would throw, what is the purpose of portable_path?
>> "/foo/bar" is perfectly reasonable on Windows.
>It's perfectly reasonable but it doesn't have a portable meaning. It
>is a relative path w.r.t. the drive of the current directory.

Almost all paths are relative w.r.t. something, the current users filesystem
mapping, the computer, the network. I don't see how leaving out the drive
makes it less portable then leaving out the computer name.

>>>This is also a way we could solve the whole problem of absolute paths.
>>>It's clear that "/foo" isn't an absolute native windows path.
>> This is not at all clear. I have and will contain to argue that "/foo" is
>> absolute windows path, since it does not respect the current
>> directory.
>If you define anything that is not relative to the current directory
>as absolute, maybe you can say that. It seems perverse to say that a
>path which is _relative_ to something other than the machine in use
>is absolute, though.
>> Also very important to me, this goes well with the URI definitions
>> of absolute and relative
>I'm pretty sure this is an illusion! URIs don't have a notion of
>"current drive" do they?

URIs are a multirooted system that have the semantics I'm advocating for
file paths. To make an example, if you are looking at
"http://localhost/somedir/index.html" it might have an absolute (as defined
by the RFCs) href of "/foo/bar" that takes you to "http://localhost/foo/bar"
and another relative (again, as defined by the RFCs) href of "foo/bar" that
takes you to "http://localhost/somedir/foo/bar". This is because paths,
relative or absolute, are with respect to the authority (localhost in this

If you can give me an example of a multirooted system that refers to paths
that are absolute with respect to the current directory as relative I'd be
interested, my multirooted experience is limited to CP/M, DOS, AmigaOS,
OS/2, Windows, and URLs. I don't have any big system experience with them.

>> and it would be nice if the path class could support full URIs.
>Are we talking about native or "portable" representation now?
>There's no reason they couldn't support full URIs in their portable
>representation. It's just a question of how that gets mapped onto
>the native filesystem.

What I'm thinking of may not be in the scope of the filesystem library, I'd
like a path class that could directly manipulate URLs; authoritys,
fragments, options and all. Direct use of "file:/.." URLs would be good too.


Boost list run by bdawes at, gregod at, cpdaniel at, john at