Re: [boost] any

From: Peter Dimov (pdimov_at_[hidden])
Date: 2000-09-07 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 self-comparison 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 statically-typed 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.