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).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk