From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-09-06 11:04:59
In message <008f01c0180c$6d252940$070524d4_at_pdimov>, Peter Dimov
>> 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
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 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