Re: [boost] any

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-09-05 08:50:02

In message <001f01c0172e$65dd24a0$540a24d4_at_pdimov>, Peter Dimov
<pdimov_at_[hidden]> writes
>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
appropriate attention.

>> 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.
>
>Why?

struct empty
{
};

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
quite ;-)

>> >Not exactly. ref(int(4)) < ref(int(5)) doesn't have anything to do with
>> >before().
>>
>> 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:  [phone]
  Curbralan Limited               mobile: [phone]
  mailto:kevlin_at_[hidden]     fax:    [phone]
  http://www.curbralan.com
____________________________________________________________