[boost] Re: path::leaf()
Beman Dawes <[EMAIL PROTECTED]> writes: > At 10:08 PM 8/25/2003, David Abrahams wrote: > >David Abrahams <[EMAIL PROTECTED]> writes: > > > >> > What about: > >> > > >> > assert( p.branch_path().empty() ); > >> > > >> > Isn't that closer to what you are trying to express? > >> > >> I guess so. I didn't see branch_path(). > > > >BTW, it would feel much more natural to me if it were > > > > path root() const; > > path branch() const; > > path leaf() const; > > > >but because of the portable-ization of non-portable windows path > >constructs, I think something this simple is impossible. > > It isn't just Windows - multi-rooted file systems with named roots are > a feature of many operating systems. Not to mention URI/URL's. It isn't multi-rooted systems which cause the problem, though. It's the need to represent paths that are only rooted under some notion of "the current root", e.g. the windows path "/foo". -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: path::leaf()
At 10:08 PM 8/25/2003, David Abrahams wrote: >David Abrahams <[EMAIL PROTECTED]> writes: > >> > What about: >> > >> > assert( p.branch_path().empty() ); >> > >> > Isn't that closer to what you are trying to express? >> >> I guess so. I didn't see branch_path(). > >BTW, it would feel much more natural to me if it were > > path root() const; > path branch() const; > path leaf() const; > >but because of the portable-ization of non-portable windows path >constructs, I think something this simple is impossible. It isn't just Windows - multi-rooted file systems with named roots are a feature of many operating systems. Not to mention URI/URL's. Early versions of the interface had only the three decomposition functions you mention above. IIRC, they even had those names. Almost immediately users came up with cases where they needed to distinguish between the root name and the root directory. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: path::leaf()
At 09:48 PM 8/25/2003, David Abrahams wrote:
>"Rainer Deyke" <[EMAIL PROTECTED]> writes:
>
>> It is my understanding that paths are implemented as
>> std::vector or something similar, where the individual
>> strings can contain slashes if the underlying filesystem allows it.
>> It would be a shame if filesystem::path was unable to represent
>> legal native paths just because they contain characters which have
>> special meaning in the portal path grammar.
>>
then 'p.leaf()' may contain any character that is supported by the
native file system, which may include slashes. When 'p.leaf()' is
then converted back into a 'filesystem::path', the resulting path
will have different sematics than intended. This strikes me as very
dangerous.
>>>
>>> Oh, is that what happens now? Yipes!
>>
>> Yipes indeed.
>
>I am finding Rainer's arguments quite convincing. Beman, what do you
>think about this?
When this was discussed in the past, one suggested solution was to
represent slashes via an escape mechanism. That's the approach RFC2396
takes. The other suggestion was to treat slashes like '\0'; just ban them.
But that discussion never went anywhere since it isn't an issue for the
current POSIX/Windows implementation.
I'm certainly in agreement that before adding implementations for any file
or operating systems that would have that problem we have to deal with it
safely.
>Also, his last point makes me think that perhaps path ought to have
>push_back so we can *add* an element with a slash in it.
>
>If a path really *is* a container of strings, I have no problem with
>having functions which build paths by parsing strings in various ways,
>but it seems like those functions don't belong in the path
>constructor. What about, simply:
>
> struct path : std::vector
> {
> // forwarding constructors
> };
I really don't view a path as a container of strings, at least not to the
point of being willing to publicly derive from std::vector. A
container of strings seems a really useful conceptual model for how a path
might store data internally. That conceptual model has helped answer
various questions that were really troublesome before the model. But the
intent was always to hand-tailor the actual interface to make it easy to
write the kinds of code envisioned as the typical uses of the library.
--Beman
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: path::leaf()
David Abrahams <[EMAIL PROTECTED]> writes: > > What about: > > > > assert( p.branch_path().empty() ); > > > > Isn't that closer to what you are trying to express? > > I guess so. I didn't see branch_path(). BTW, it would feel much more natural to me if it were path root() const; path branch() const; path leaf() const; but because of the portable-ization of non-portable windows path constructs, I think something this simple is impossible. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: path::leaf()
Beman Dawes <[EMAIL PROTECTED]> writes: > At 03:55 PM 8/21/2003, David Abrahams wrote: > > >Beman Dawes <[EMAIL PROTECTED]> writes: > > > >> At 08:31 PM 8/19/2003, David Abrahams wrote: > >> > > >> >It surprised me a bit that leaf returns a string instead of a path. > >> > >> The rule isn't entirely obvious. If a decomposition function can > >> possibly return more that one element, it is returned as type path. If > >> at most a single element is returned, the return type is std::string. > > > >It may not surprise you, but the easy translation between paths and > >strings really rubs me the wrong way. Practically the only reason I'm > >using the path class at all is to increase the level of abstraction > >and self-documentation of the code I'm writing -- I think it's foolish > >to pass around something called std::string when it really represents > >a file path. A single component of a path is still a path, and it > >shouldn't devolve into a string. > > > >I'm rewriting some Java code in C++ which has a "Directory" > >abstraction, that lets you open files in that directory. I want those > >functions take path parameters. I want to assert that they're leaf > >paths. Having to write: > > > >assert(path(p.leaf()) == p) > > > >or > > > > assert(p.leaf() == p.string()) > > > >instead of: > > > > assert(p == p.leaf()) > > > >really feels odd to me. > > What about: > > assert( p.branch_path().empty() ); > > Isn't that closer to what you are trying to express? I guess so. I didn't see branch_path(). > >> >Shouldn't > >> > > >> > "foo/bar"/p.leaf() > >> > > >> >work? > >> > >> Yes, via the automatic conversion. I just added a test case to > >> path_test to verify that. Yes, it does work. I expect there would > >> have been scads of bug reports if it didn't work. > > > >Whoa. What code and compiler did you test that with? > > Ah! I corrected your code first so that "foo/bar" was a path. There is > no operator/ for string arguments, of course. Of course; that was the point of what I was saying. you can write cstring/path, but not cstring/std::string; I think it's reasonable to combine the leaf of a path with path strings if that's something you can normally do with a full path. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: path::leaf()
"Rainer Deyke" <[EMAIL PROTECTED]> writes:
> David Abrahams wrote:
>> "Rainer Deyke" <[EMAIL PROTECTED]> writes:
>>
>>> David Abrahams wrote:
A single component of a path is still a path, and it
shouldn't devolve into a string.
>>>
>>> I disagree. While a path with just one component can exist, a
>>> single path component is no more a path than an element in an array
>>> of integers is itself an array of integers.
>>> A single component of a path is a name, and therefore naturally
>>> represented by 'std::string'.
>>
>> Are you seriously saying that path("foo") is not a path?
>
> No. "foo" is a path element. path("foo") is a path with one element.
>
>> If you want
>> to make paths into containers of strings, give them iterators and
>> operator[], and I'll accept the name back() as a way to get the leaf
>> string.
>
> Paths already have iterators to iterate over the path elements. I agree
> that 'back' would be a better name what is currently called 'leaf', since
> this frees the 'leaf' name to return a path instead of a string.
>
>>> If 'p' is a native path
>>
>> Is there such a thing as a "native path"? I thought all path strings,
>> even if they began as native, got converted immediately into some
>> "portable generic" format internally.
>
> It is my understanding that paths are implemented as
> std::vector or something similar, where the individual
> strings can contain slashes if the underlying filesystem allows it.
> It would be a shame if filesystem::path was unable to represent
> legal native paths just because they contain characters which have
> special meaning in the portal path grammar.
>
>>> then 'p.leaf()' may contain any character that is supported by the
>>> native file system, which may include slashes. When 'p.leaf()' is
>>> then converted back into a 'filesystem::path', the resulting path
>>> will have different sematics than intended. This strikes me as very
>>> dangerous.
>>
>> Oh, is that what happens now? Yipes!
>
> Yipes indeed.
I am finding Rainer's arguments quite convincing. Beman, what do you
think about this?
Also, his last point makes me think that perhaps path ought to have
push_back so we can *add* an element with a slash in it.
If a path really *is* a container of strings, I have no problem with
having functions which build paths by parsing strings in various ways,
but it seems like those functions don't belong in the path
constructor. What about, simply:
struct path : std::vector
{
// forwarding constructors
};
??
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: path::leaf()
At 03:55 PM 8/21/2003, David Abrahams wrote: >Beman Dawes <[EMAIL PROTECTED]> writes: > >> At 08:31 PM 8/19/2003, David Abrahams wrote: >> > >> >It surprised me a bit that leaf returns a string instead of a path. >> >> The rule isn't entirely obvious. If a decomposition function can >> possibly return more that one element, it is returned as type path. If >> at most a single element is returned, the return type is std::string. > >It may not surprise you, but the easy translation between paths and >strings really rubs me the wrong way. Practically the only reason I'm >using the path class at all is to increase the level of abstraction >and self-documentation of the code I'm writing -- I think it's foolish >to pass around something called std::string when it really represents >a file path. A single component of a path is still a path, and it >shouldn't devolve into a string. > >I'm rewriting some Java code in C++ which has a "Directory" >abstraction, that lets you open files in that directory. I want those >functions take path parameters. I want to assert that they're leaf >paths. Having to write: > >assert(path(p.leaf()) == p) > >or > > assert(p.leaf() == p.string()) > >instead of: > > assert(p == p.leaf()) > >really feels odd to me. What about: assert( p.branch_path().empty() ); Isn't that closer to what you are trying to express? >> >Shouldn't >> > >> > "foo/bar"/p.leaf() >> > >> >work? >> >> Yes, via the automatic conversion. I just added a test case to >> path_test to verify that. Yes, it does work. I expect there would >> have been scads of bug reports if it didn't work. > >Whoa. What code and compiler did you test that with? Ah! I corrected your code first so that "foo/bar" was a path. There is no operator/ for string arguments, of course. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
