Re: [boost] any

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-09-06 11:04:59

In message <008f01c0180c$6d252940$070524d4_at_pdimov>, Peter Dimov
<pdimov_at_[hidden]> writes
>> 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.
>
>I think that the above should be "two separate compilations", but I may be
>wrong.

IIRC from a BSI C++ panel mtg where this came up, it is executions.

>> For type_info::before this is not a
>> problem: before is not operator<.
>
>Depends on what your intuition leads you to assume about operator<.

I think that would be a fair summary of everything already said, and
probably everything that will be said :->

>> struct empty
>> {
>> };
>>
>> ref<empty> lhs(empty()), rhs(empty());
>>
>> Is lhs < rhs, rhs < lhs, lhs == rhs, or none of these?
>
>!(lhs < rhs)
>!(rhs < lhs)
>
>Whether lhs == rhs is debatable (in terms of op==; in terms of op< they are
>equivalent.) I haven't decided on this yet.

Well, it's the fact that all comparisons currently return false that is
part of the issue I was getting at.

>Of course, ref<> provides a strict weak ordering only if you don't
>deliberately break it by putting objects with broken op< in it. This is a
>reasonable assumption, IMHO.

Therefore a precondition to operator< working is that the contents have
a valid operator<? In which case, would it make sense to indicate a
constraint violation if not? Given the runtime nature of this, that
seems to call for an exception.

>> ref<> does interpret types, albeit in a limited fashion, otherwise you
>> cannot establish any ordering.
>
>No, it doesn't interpret types. It can only compare them for equality. The
>fact that int can implicitly convert to double is well beyond that.

Yes, it does interpret types: there are actions being performed that are
dependent on the type. I am not talking about the more general case of
converting between different types, just the idea that "Oh, you're one
of these, and so are you, therefore I can do this, otherwise I'd have
had to do that".

>> 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.
>
>ref's approach to ordering is consistent.

One could argue that having such a three part condition is consistent...
but I wouldn't ;-) I would certainly say that it could be subtle.

>ref(T t) < ref(U u) iff T < U || (T == U && t < u).

That's not the same as what the current ref<> does.

Kevlin
____________________________________________________________

  Kevlin Henney                   phone:  [phone]
  Curbralan Limited               mobile: [phone]
  mailto:kevlin_at_[hidden]     fax:    [phone]
  http://www.curbralan.com
____________________________________________________________