Re: [boost] Please don't define a fake"operator<"just for ordered containers

From: Sean Parent (sparent_at_[hidden])
Date: 2006-07-11 17:19:18

> 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  
proposing that the standard be extended to require std::pair<> to  
supply a less<> specialization.
> 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  
that a minor inconvenience.

(should we move the discussion to the std reflector?)

Sean