[boost] Re: [filesystem] operator<(path, path)?
Beman Dawes <[EMAIL PROTECTED]> writes: > At 07:46 AM 8/23/2003, David Abrahams wrote: > > >But paths do have such an ordering. It's a lexicographic compare on > >the conceptual underlying vector they contain. In other words > > > >x.m_name < y.m_name > > > >Unfortunately, that vector isn't available to clients of path so you > >have to use x.string() < y.string(), which is only a poor substitute > >for the actual vector. > > The hope is that the ability to iterate over the elements of the > implied vector would serve as well as an actual vector. Good point; I keep overlooking that it's iterable. > Thus the begin() and end() members. The assumption was that in the > rare cases where an actual std::vector was needed, it would be easy > enough to copy from begin(),end(). > > Off the top of my head, I'd think path::iterator would be sufficient > for std::lexicographic_compare(), or is that not what you had in > mind? No, I think you're right; it would be. My thinking was just limited by, er... confusing paths with strings ;-) -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [filesystem] operator<(path, path)?
At 07:46 AM 8/23/2003, David Abrahams wrote: >But paths do have such an ordering. It's a lexicographic compare on >the conceptual underlying vector they contain. In other words > >x.m_name < y.m_name > >Unfortunately, that vector isn't available to clients of path so you >have to use x.string() < y.string(), which is only a poor substitute >for the actual vector. The hope is that the ability to iterate over the elements of the implied vector would serve as well as an actual vector. Thus the begin() and end() members. The assumption was that in the rare cases where an actual std::vector was needed, it would be easy enough to copy from begin(),end(). Off the top of my head, I'd think path::iterator would be sufficient for std::lexicographic_compare(), or is that not what you had in mind? --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [filesystem] operator<(path, path)?
At Friday 2003-08-22 13:06, you wrote:
At 11:35 PM 8/21/2003, David Abrahams wrote:
>Beman Dawes <[EMAIL PROTECTED]> writes:
>
>> At 06:38 PM 8/21/2003, David Abrahams wrote:
>>
>> >I need to make a mapping over paths. Is there any important reason
>> >there's no operator< provided?
>>
>> I don't think it has been discussed. I've had the need myself, but
>> worked around it by using path::string() to generate the key.
>>
>> There were a number of discussions about operator== and !=. They can
>> be subject to serious abuse and misunderstanding, and so are left
>> out.
>
>Whoa, really?
>
>> I'm still not sure if that was the right decision, so might be
>> willing to review it.
>
>I'm curious about it, anyway.
Is path("abc")==path("ABC") true in the sense of being the same path? The
correct answer is yes, no, or maybe, depending on the operating system.
There are a ton of other examples where two paths which are textually
different are sometimes the same path.
The counter argument is that defining path equality as path::string()
equality seems natural, even if it doesn't answer the "are they the same
path?" question. But this does lead to fragile programs; we can see that
in the Boost regression test reporting where slight changes in the way
bjam reports paths often break the status tables (which rely on
assumptions about path equality.) operator== on paths can be a sign of
poor, or at least fragile design.
are we going to suggest to the core committee that somefloat ==
someotherfloat be removed from the language. Certainly the fragility on
path can be no worse.
--Beman
PS: I just changed the FAQ entry to use that example; it is clearer than
the one given before.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com
The five most dangerous words in the English language:
"There oughta be a law"
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [filesystem] operator<(path, path)?
Daryle Walker <[EMAIL PROTECTED]> writes: > On Thursday, August 21, 2003, at 10:12 PM, Beman Dawes wrote: > >> At 06:38 PM 8/21/2003, David Abrahams wrote: >> >>> I need to make a mapping over paths. Is there any important reason >>> there's no operator< provided? >> >> I don't think it has been discussed. I've had the need myself, but >> worked around it by using path::string() to generate the key. >> >> There were a number of discussions about operator== and !=. They can >> be subject to serious abuse and misunderstanding, and so are left >> out. I'm still not sure if that was the right decision, so might be >> willing to review it. >> >> Anyhow, we should be able to support maps and sets of paths. I'll >> try to give it some thought in the morning when I'm wider awake. > > If it isn't safe to even have the equality operators, then having the > ordered inequality operators may not be safe either. If David has an > ordering he wants to use in mind, then a custom comparison function > object class can be made. > > I've seen quite a few requests for operator<() for class that don't > have it (e.g. std::complex<>) just for the purpose of using it as an > element type of an associative container. Forcing a type of have such > an operator, even when it's inappropriate (i.e. the type doesn't > suggest an overwhelmingly-natural ordering), defeats the purpose of > the associative container class templates having comparator types in > the first place! But paths do have such an ordering. It's a lexicographic compare on the conceptual underlying vector they contain. In other words x.m_name < y.m_name Unfortunately, that vector isn't available to clients of path so you have to use x.string() < y.string(), which is only a poor substitute for the actual vector. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [filesystem] operator<(path, path)?
On Thursday, August 21, 2003, at 10:12 PM, Beman Dawes wrote: At 06:38 PM 8/21/2003, David Abrahams wrote: I need to make a mapping over paths. Is there any important reason there's no operator< provided? I don't think it has been discussed. I've had the need myself, but worked around it by using path::string() to generate the key. There were a number of discussions about operator== and !=. They can be subject to serious abuse and misunderstanding, and so are left out. I'm still not sure if that was the right decision, so might be willing to review it. Anyhow, we should be able to support maps and sets of paths. I'll try to give it some thought in the morning when I'm wider awake. If it isn't safe to even have the equality operators, then having the ordered inequality operators may not be safe either. If David has an ordering he wants to use in mind, then a custom comparison function object class can be made. I've seen quite a few requests for operator<() for class that don't have it (e.g. std::complex<>) just for the purpose of using it as an element type of an associative container. Forcing a type of have such an operator, even when it's inappropriate (i.e. the type doesn't suggest an overwhelmingly-natural ordering), defeats the purpose of the associative container class templates having comparator types in the first place! Daryle ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [filesystem] operator<(path, path)?
Beman Dawes <[EMAIL PROTECTED]> writes:
> At 11:35 PM 8/21/2003, David Abrahams wrote:
> >Beman Dawes <[EMAIL PROTECTED]> writes:
> >
> >> At 06:38 PM 8/21/2003, David Abrahams wrote:
> >>
> >> >I need to make a mapping over paths. Is there any important reason
> >> >there's no operator< provided?
> >>
> >> I don't think it has been discussed. I've had the need myself, but
> >> worked around it by using path::string() to generate the key.
> >>
> >> There were a number of discussions about operator== and !=. They can
> >> be subject to serious abuse and misunderstanding, and so are left
> >> out.
> >
> >Whoa, really?
> >
> >> I'm still not sure if that was the right decision, so might be
> >> willing to review it.
> >
> >I'm curious about it, anyway.
>
> Is path("abc")==path("ABC") true in the sense of being the same path?
> The correct answer is yes, no, or maybe, depending on the operating
> system. There are a ton of other examples where two paths which are
> textually different are sometimes the same path.
>
> The counter argument is that defining path equality as path::string()
> equality seems natural, even if it doesn't answer the "are they the
> same path?" question. But this does lead to fragile programs; we can
> see that in the Boost regression test reporting where slight changes
> in the way bjam reports paths often break the status tables (which
> rely on assumptions about path equality.) operator== on paths can be a
> sign of poor, or at least fragile design.
I think this comes from confusing paths with strings. IMO a path
should not just be a wrapper around a string. *If* paths are really
supposed to be "portable/generic" (and if you ask "portable/generic
what?" I'll say "identifiers of an address in the filesystem), and if
that constructor form builds paths from "portable/generic textual
representation" then I guess I'd have to say those aren't equal.
path("abc", native)==path("ABC", native)
may be another matter. But if you're allowing slashes in path
element representation, even under some circumstances, you can't very
well define equality as simple string equality. This is why I'm
saying paths are not strings.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [filesystem] operator<(path, path)?
At 11:35 PM 8/21/2003, David Abrahams wrote:
>Beman Dawes <[EMAIL PROTECTED]> writes:
>
>> At 06:38 PM 8/21/2003, David Abrahams wrote:
>>
>> >I need to make a mapping over paths. Is there any important reason
>> >there's no operator< provided?
>>
>> I don't think it has been discussed. I've had the need myself, but
>> worked around it by using path::string() to generate the key.
>>
>> There were a number of discussions about operator== and !=. They can
>> be subject to serious abuse and misunderstanding, and so are left
>> out.
>
>Whoa, really?
>
>> I'm still not sure if that was the right decision, so might be
>> willing to review it.
>
>I'm curious about it, anyway.
Is path("abc")==path("ABC") true in the sense of being the same path? The
correct answer is yes, no, or maybe, depending on the operating system.
There are a ton of other examples where two paths which are textually
different are sometimes the same path.
The counter argument is that defining path equality as path::string()
equality seems natural, even if it doesn't answer the "are they the same
path?" question. But this does lead to fragile programs; we can see that in
the Boost regression test reporting where slight changes in the way bjam
reports paths often break the status tables (which rely on assumptions
about path equality.) operator== on paths can be a sign of poor, or at
least fragile design.
--Beman
PS: I just changed the FAQ entry to use that example; it is clearer than
the one given before.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
