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
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
> less<K> is encountered, the implementation is entitled to use
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
> 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
> and if this happens, shared_ptr ought to also be changed to reflect
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?)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk