Boost logo

Boost :

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
> > 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
> 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
> object gives unspecified results, as described in the standard in
> And shared_ptr pointers are always pointers of this kind and not
> to array elements or the other categories of pointers where the
meaning of
> comparison is specified. However, std::less on C++ pointers is
> 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
> 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
> 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
> 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
> comparison operators too, being sure to use std::less on the
> 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at