smart_ptr and std::less (was Re: Smart pointer status, directions, thoughts)

From: williamkempf_at_[hidden]
Date: 2001-05-24 12:36:17

--- In boost_at_y..., Darin Adler <darin_at_b...> wrote:
> On Thursday, May 24, 2001, at 07:01  AM, Peter Dimov wrote:
> 
> > I have some comments on shared_ptr.
> >
> > 1. Isn't specializing std::less without defining the 
corresponding 
> > operator<
> > setting a dangerous precedent? This means that sort(f, l) and sort
(f, l,
> > less<>()) could potentially give different results.
> 
> No, I don't think it's setting a precedent.
> 
> C++ pointers themselves have a slightly more severe version of the 
same 
> problem. Calls to sort (f, l), and sort (f, l, less<>()) can give 
> different results for an array of pointers, for example.
> 
> A comparison between two pointers that are not pointers within the 
same 
> object gives unspecified results, as described in the standard in 
5.9p2. 
> And shared_ptr pointers are always pointers of this kind and not 
pointers 
> to array elements or the other categories of pointers where the 
meaning of 
> comparison is specified. However, std::less on C++ pointers is 
guaranteed 
> to provide a total ordering even when the < operator does not, as 
> described in the standard in 20.3.3p8.

Yeah, I didn't think the implications of the rules for shared_ptr 
through.  It doesn't make sense to have an operator< for shared_ptr.

> So shared_ptr reflects this underlying behavior in a few ways:
> 
> 	1) It provides a std::less specialization. Thus shared_ptr 
objects 
> will work in associative containers -- the primary motivation for 
> providing it -- and also in other code where the programmer 
carefully uses 
> std::less instead of relying on the < operator.
> 	2) It doesn't provide the < operator. Thus sort (f, l) will 
fail to 
> compile rather than relying on unspecified behavior. I think this 
is good 
> and helps people write portable code.
> 	3) The implementation of the std::less specialization uses 
the 
> underlying std::less for pointers. This means that we get the total 
> ordering we want even on platforms where the < operator and 
std::less give 
> different results for pointers
> 
> Andrei Alexandrescu made the same choice for his SmartPtr class 
template. 
> In his _Modern C++ Design_ his discusses this issue in Section 7.9, 
> "Ordering Comparisons".
> 
> An alternative choice would be to define the < operator and the 
other 
> comparison operators too, being sure to use std::less on the 
underlying 
> pointer rather than using the < operator. But I don't think this 
would be 
> an improvement.

Not only would it not be an improvement, it would be a bad idea.  It 
makes shared_ptr<> even less like a real pointer.

Bill Kempf