|
Boost : |
From: Peter Dimov (pdimov_at_[hidden])
Date: 2000-09-07 07:49:21
> I think it is strange (nonintuitive, indeed) to define relational
> operators such that
>
> !(a < b) && !(b < a) does not imply a == b
>
> Don't you think?
I agree. However, if you have a class that has only op<, or has neither, I
want ref to be able to handle it.
In other words, I leave this sort of design decisions to the user.
Whether the default op== should return true or false is an interesting
question. This is the 'value' vs. 'identity' equality semantics problem.
Good arguments exist in favour of either.
> Except when they don't have an operator<: How can you produce the same
> ordering as the statically-typed version when the statically-typed
> version does not compile? Mu!
Of course. An user that puts objects without an op< defined into refs and
then sorts the container gets what (s)he deserves.
> This also brings us back again to T < U being intuitive: Until you
> started outlining ref<>'s semantics, the only common definition of which
> I was aware for interpreting this notation was "T is a subtype of U"
> (which is not in fact a strict weak ordering). Hmm, even since, I still
> reckon that's the only common definition ;-)
This is discussed in D & E. Good arguments exist against the T < U ::= U
is-a T definition.
> No, in fact, I'm even more convinced: How can "unspecified" be a more
> intuitive definition than "is a subtype of", or "is included within", or
> "is less than", or "is lexicographically less than"? Just because it has
> wings doesn't mean it can fly.
I would have certainly preferred a standard total ordering of types. This
would have made it possible to write portable persistence libraries that do
not rely on the user registering all types with some unique identifiers.
A standard type_info::name() could have served that purpose.
Unfortunately, the standard states that the compiler is not required to
impose a specified total ordering on types. How could I?
-- 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