Sean Parent wrote:

...

From item 6 - I'd remove the operator < from shared_ptr. If we were going to keep operator < for shared ptr, then I would have to argue to change all of the examples from 6 for consistency (or provide a semantic difference between shared_ptr and these cases.

There are two problems with using std::less instead of operator< to supply a set/map order. First, it doesn't propagate to composite types; if you provide a specialization of less<K>, less< pair<K, int> > doesn't work. Well the same is true for operator < and a simple struct. I'm

Second, less<K> is defined as always using K::operator< unless K is a raw pointer; it is basically a different name for operator<, one that can be used as a predicate. This gives rise to the interpretation that wherever less<K> is encountered, the implementation is entitled to use K::operator< directly. Not true. 10.3.3.8 gives a fair amount of leeway in the case where operator < does not provide a total ordering (a raw pointer is the only instance given in the standard). We are allowed to specialize classes in the standard with our own types. So boost::tuple could specialize std::less<> without raising any conflicts. This could have been avoided by defining a separate relation for set/map order, either as a function reachable via ADL, or as a function object, then making sure that it is defined for all standard value types. Why is this necessary? std::less<> serves us well and avoids the whole ADL mess. With suitable changes to the standard, less<K> can be made that relation, and if this happens, shared_ptr ought to also be changed to reflect that. There isn't any reason that I can find in the standard not to use less<K> for shared_ptr. It won't work with std::pair<> but I consider

proposing that the standard be extended to require std::pair<> to supply a less<> specialization. that a minor inconvenience. (should we move the discussion to the std reflector?) Sean