From: Peter Dimov (pdimov_at_[hidden])
Date: 2000-09-05 06:42:32
> >If you use std::map and std::set as a map (associative array) and a set,
> >while considering the fact that they are based on an ordering an
> >implementation detail, a map<any, T> is more intuitive than map<any, T,
> Quite the contrary, I'm afraid. I would prefer to see the unintuitive
> ordering made explicit. There are many practical reasons that the std
> associative containers allow this template parameter, and one of them is
> to ensure that people are not forced into writing unintuitive operator<
ref::op< is intuitive to me. But this point is unprovable, because
"intuitive" cannot be formally defined.
Let me put it this way: give me two examples of comparison objects that
allow std::map<any, T, comparison_object> and define an ordering that is
significantly different from the ordering defined by ref::op<.
ref::op< is simply the only sensible ordering for refs (and anys) if you
don't have domain specific knowledge about the set of types stored.
> I would contend that lexicographical ordering fits into that model, esp
> when looking through a dictionary. However, that is my intuitive
> understanding, and the std only requires that the ordering is strict and
> weak, which ref<> also does not satisfy.
> And less<T*> is, in principle, specialised for this purpose. Would you
> rather that pointers had this total ordering?
Yes. And in practice they already do on many platforms.
> I think I would prefer to
> see less<> specialised for ref<> than having operator< provided.
I may be wrong, but I think that you can already compare anys using < - and
the results are worse than ref::op<.
> >Not exactly. ref(int(4)) < ref(int(5)) doesn't have anything to do with
> Exactly: the result of ref(double(4)) < ref(int(5)) is unspecified.
It has to be unspecified if you don't know that 'int' is an int and 'double'
is a double. ref does not interpret types. Neither does any.
ref(T) < ref(U) is unspecified. This is the only intuitive resolution. (It
is also totally ordered in the same way that type_info::before() provides an
unspecified, but total ordering.)
> Sounds like very bad news to me. I think that standard/common practice
> on this is pretty clear, and that ref<> does not follow it :-(
ref(double(4.0)) < ref(int(5)) would imply that ref is a category (3)
object, i.e. an 'any' that knows about similar types and can convert between
them. This is not a part of our design goals, as you have stated yourself.
-- 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