From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-09-04 11:08:54
In message <01e301c01684$8b9d2640$3e0524d4_at_pdimov>, Peter Dimov
>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<
>> Because it does not represent a magnitude-based comparison. It conforms
>> to the principle of least astonishment, for the simple reason that
>> operator< implies an obvious, total-ordering comparison for a type.
>std::string::op< does not represent a magnitude-based comparison either.
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.
>less<T*> is required to provide an ordering suitable for map and set,
>although there is no obvious, total-ordering comparison on pointers that
>point to different objects.
And less<T*> is, in principle, specialised for this purpose. Would you
rather that pointers had this total ordering? I think I would prefer to
see less<> specialised for ref<> than having operator< provided.
>> same applies to ref<>, except that ref<> spells before() -- incorrectly,
>> IMHO -- as operator< ;-)
>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.
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 :-(
Kevlin Henney phone: +44 117 942 2990
Curbralan Ltd mobile: +44 7801 073 508
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