Boost logo

Boost :

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2000-02-28 09:41:11


From: Kevlin Henney <kevlin_at_[hidden]>
> In message <Pine.LNX.4.10.10002272359490.17343-100000_at_boneone.endoframe.
> com>, Braden N. McDaniel <braden_at_[hidden]> writes
> >Kevlin: I think I see your point. But while it's true that the particulars
> >the ordering implied by operator< are almost certainly uninteresting, this
> >really isn't the point. I think it may be useful for a containter to be
> >keyed on a shared_ptr: for some uses of std::set and std::map, the order
> >of the elements may be uninteresting to the user; rather, the use of these
> >containers may be motivated by other features.
> >
> >It is certainly true that one can create one's own comparator (either a
> >specialization of std::less or something original). However, having
> >operator< available to suit the default case seems like a useful
> >convenience.
>
> I think that operator< solves the wrong problem and sends out the wrong
> signals: If the problem is that you wish to have a std::set of
> shared_ptr the default case solution is to provide a Boost
> specialisation of std::less, not operator<. Overloading operator<
> strongly suggests that there is an interesting and easily repeatable
> ordering (ie across program executions), which is not the case.
>
> Given that the standard does not assume a total ordering for pointers
> based on operator<, it seems a little presumptuous to introduce it for
> shared_ptr. The irony is that to implement operator< you would have to
> do it in terms of std::less on the underlying pointer :->

And in the header for shared_ptr I see the following, so there is
nothing missing here:

// 30 Nov 99 added operator ==, operator !=, and std::swap and std::less
// specializations for shared types (Darin Adler)


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk