|
Boost : |
From: David Abrahams (dave_at_[hidden])
Date: 2003-08-22 21:27:49
Beman Dawes <bdawes_at_[hidden]> writes:
> At 11:35 PM 8/21/2003, David Abrahams wrote:
> >Beman Dawes <bdawes_at_[hidden]> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk