On 10 October 2013 18:24, Gabriel Dos Reis <gdr_at_[hidden]> wrote:

> Nevin Liber <nevin_at_[hidden]> writes:
>
> | [Y'know, I really wish replies would by default go the whole ub group...]
>
> I cannot control your email software, but when you sent me the message,
> it wasn't addressed to the group and I replied the same way.
>

It isn't my software (Gmail web client); it's the mailing list. All the
other reflectors default to replying to the group; this one defaults to
replying only to the original author. I'm not sure who to contact to get
that changed.


>
>
> As observed by Sean Parent in another discussion, std::less<T*> as a
> total order was never meant to be synonymous for operator< on pointers.
>

Sean also says in [c++std-lib-ext-550]: The definition of std::less should
be "a representational order if no natural total order (operator <) is
available, otherwise the natural total order". He goes on: "They are named
separately, operator<() is the natural total order and std::less<> is the
natural total order if one exists, otherwise it is a representational
order."

Pointers clearly violate those rules.

Of course, C++ experts live with these contradictory rules all the time.
 That's what makes them experts... :-( Some experts even argue we should
keep this contradictory behavior without providing concrete reasons why it
is still necessary.


> | If someone writes:
> |
> | struct Foo
> | {
> | X x;
> | Y y;
> | Z z;
> |
> | friend bool operator<(Foo const& l, Foo const& r)
> | { return std::tie(l.x, l.y, l.z) < std::tie(r.x, r.y, r.z); }
>
> in my book, that someone writing this isn't a novice, but we have
> already disagreed on this.
>


It doesn't take an expert to want to use an object as a key in a set or a
map. I was assuming that novices had access to Boost; if you don't want to
make that assumption, I'm fine with that too.


> | };
> |
> | If X, Y or Z are pointers, this code is broken!
>
> If X, Y, and Z are pointers, I don't think he or she would have written
> that.
>

Show us how you believe a novice would write this:

If X, Y, Z are types that can be used as keys in a set (why should it
matter whether or not they are pointers?), what does the novice have to
write so that a struct of them can be used as a key in a set?

Then show us how the expert should write this, with the additional caveat
that it works with all of the relation comparators (less, greater,
less_equal, greater_equal, assuming X, Y and Z can also be used correctly
with those comparators) provided by the standard library. Again, this
should not be something that is hard to do.

And in a simpler world, both the novice solution and the expert solution
ought to match...

-- 
 Nevin ":-)" Liber  <mailto:nevin_at_[hidden]>  (847) 691-1404