
Boost : 
From: Peter Dimov (pdimov_at_[hidden])
Date: 20000907 06:13:54
> >> 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.
The standard does not assume that !(a < b) && !(b < a) implies a == b.
The reason that the default op== returns false is that a reference counted
implementation would be able to return true on selfcomparison and false
otherwise:
ref<void> rv1(empty()), rv2(rv1), rv3(empty());
assert(rv1 == rv2);
assert(rv1 != rv3);
In either case, this has nothing to do with op<.
> Therefore a precondition to operator< working is that the contents have
> a valid operator<?
No. ref::operator<, when invoked on refs holding objects of the same type T,
produces the same ordering as the staticallytyped version.
ref does not impose its own definition of "working."
> 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.
The only case where ref::op< doesn't "work" is when you have an op<
somewhere in the program that doesn't "work" and you put objects of this
type in refs.
This is, obviously, either a bug in the user code that I don't think is
ref's responsibility to catch, or a deliberate design decision.
> >ref(T t) < ref(U u) iff T < U  (T == U && t < u).
>
> That's not the same as what the current ref<> does.
The current ref::op< does
ref(T t) < ref(U u) iff T == U? t < u: T < U
which is equivalent to the above.
 Peter Dimov Multi Media Ltd.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk