On 13 December 2011 16:42, Igor R <boost.lists@gmail.com> wrote:
> Your program might work, but anyone else who might include your operator<()> definition in their own code will be extremely surprised when this doesn't> work as expected:>    ASSERT_FALSE(shared_ptr<Foo>(new Foo()) == shared_ptr<Foo>(new Foo()));>> When I compare 2 pointers, smart or raw, I want to know if the pointers are equal not the subobjects.

Well, I'd argue with the last sentence, but please note that I wasn't
talking about operator == at all. I mentioned operator <, which is
documented in shared_ptr as follows:

Well..the last sentence was my personal opinion so I'm quite confident in it ;-)

I realised in my previous response that set::find() wouldn't need operator==, so my quote above is probably not so relevant now. As for operator<() comparisons - I don't expect I would want that comparison for pointers so a 'hijacking' of it through a global (or at least ADL-findable) operator<() is less relevant. As Lars points out though, the comparator can be provided as part of the set<> type, which is a much nicer means of providing the compare operation.
 
"Returns: an unspecified value such that operator< is a strict weak
ordering as described in section 25.3 [lib.alg.sorting] of the C++
standard; under the equivalence relation defined by operator<, !(a <
b) && !(b < a), two shared_ptr instances are equivalent if and only if
they share ownership or are both empty. Throws: nothing."
So as long as operator< implements strict weak ordering, it's fine.

The important point here IMO is that comparison is based on shared ownership. If that is the case, then Galen's implementation of isNeighbor() won't work as it's not based on ownership comparison but pointee comparison.

--
Rob Desbois
Blog: http://theotherbranch.wordpress.com/
"I disapprove of what you say, but I’ll defend to the death your right to say it", Voltaire