[boost] Re: Any good reason not to have == for shared_ptr?

From: Dave Abrahams (abrahams_at_[hidden])
Date: 1999-11-09 22:27:08

>>Hmm. I had assumed that this
>>
>>     a == b
>>
>>would compare the pointers and this
>>
>>     *a == *b
>>
>>would compare the objects.

I agree with the above.

> Perhaps I should have elaborated. What if, for example,
> you wanted to maintain a sorted vector of these shared
> pointers? You *could* still do it your way by creating
> a comparison function/functor and using it for the sort
> and for every call to find(), etc. But isn't it nicer
> to be able to define the operators == and < etc and use
> the non-comparison-function-expecting versions of all
> the calls?
>
> Another thing to keep in mind is that a lot of non-STL
> code expects those standard operators for comparison
> Maybe I'm old fashioned liking doing things that way
> when I can: I can certainly understand the counter argument.

You're assuming that comparing the pointed-to object identity is a
less-likely or useful scenario than comparing the pointed-to object
contents. I don't buy it. Consistent pointer-like semantics make sense here.
If you want to compare contents, you *could* still do it your way by
creating a comparison function/functor and using it for the sort and for
every call to find(), etc. But isn't it nicer to be able to define the
operators == and < etc and use the non-comparison-function-expecting
versions of all the calls for object identity? ;)

P.S. I don't love the idea of defining a non-member op==, etc. with an eye
towards encouraging users to specialize for the comparison of object
contents. It seems rather like a nightmare to have shared_ptr<X> and
shared_ptr<Y> differ so significantly.

P.P.S. The definition of op<, etc. for shared_ptr should use std::less<T*>,
which is well defined for all pairs of T* (just using < is not).

-Dave