From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-09-05 08:50:02
In message <001f01c0172e$65dd24a0$540a24d4_at_pdimov>, Peter Dimov
>ref::op< is intuitive to me. But this point is unprovable, because
>"intuitive" cannot be formally defined.
>Let me put it this way: give me two examples of comparison objects that
>allow std::map<any, T, comparison_object> and define an ordering that is
>significantly different from the ordering defined by ref::op<.
type_info::before will give you a different ordering.
I find the fact that whether or not operator< gives you the same
ordering on two separate executions is unspecified for the same set of
ref<> objects slightly worrying. For type_info::before this is not a
problem: before is not operator<.
>ref::op< is simply the only sensible ordering for refs (and anys) if you
>don't have domain specific knowledge about the set of types stored.
There are two points here: (1) one is that you are aiming to establish a
strict weak ordering, in the words of the standard, and (2) you need to
provide an interface for it. ref<> does not currently satisfy (1) and,
in addition to (1), realising (2) as operator< does not give you the
usual, expected properties for operator< where a name would draw
>> I would contend that lexicographical ordering fits into that model, esp
>> when looking through a dictionary. However, that is my intuitive
>> understanding, and the std only requires that the ordering is strict and
>> weak, which ref<> also does not satisfy.
ref<empty> lhs(empty()), rhs(empty());
Is lhs < rhs, rhs < lhs, lhs == rhs, or none of these?
>> And less<T*> is, in principle, specialised for this purpose. Would you
>> rather that pointers had this total ordering?
>Yes. And in practice they already do on many platforms.
That was not the question. My current platform supports operator< for
ref<>, but I don't have to like that ;->
>> I think I would prefer to
>> see less<> specialised for ref<> than having operator< provided.
>I may be wrong, but I think that you can already compare anys using < - and
>the results are worse than ref::op<.
Aagh, good point! Doesn't matter how many times you stare at a design,
it always takes another pair of eyes to make the bugs shallow. Thanks
for that: at least one of us is awake. I will fix that in the next
upload. Almost convinced me to do away with that UDC... almost, but not
>> >Not exactly. ref(int(4)) < ref(int(5)) doesn't have anything to do with
>> Exactly: the result of ref(double(4)) < ref(int(5)) is unspecified.
>It has to be unspecified if you don't know that 'int' is an int and 'double'
>is a double. ref does not interpret types. Neither does any.
ref<> does interpret types, albeit in a limited fashion, otherwise you
cannot establish any ordering.
The essential problem is that ref<> has a mix and match approach to its
idea of ordering that is inconsistent: in some cases operator< is
unspecified but provides a strict weak ordering, in others it is
specified and provides a total ordering, and in others it is specified
but does not provide an ordering.
Kevlin Henney phone: +44 117 942 2990
Curbralan Limited mobile: +44 7801 073 508
mailto:kevlin_at_[hidden] fax: +44 870 052 2289
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk