I can think of three reasons, none of them authoritative:
1. If this operator== ends up doing shared_ptr != weak_ptr.lock() under
Peter Dimov
covers, an argument could be made that the explicit version is better since it doesn't hide the overhead from the reader;
2. There are two sensible meanings for such an operator (as explained in N1590), "points to the same address" and "shares ownership with"; it might be better to leave the choice to the user and, again, to keep the choice explicit to benefit the reader;
I guess I presumed it could be implemented as a test for shared ownership possibly followed by a test for pointer equality, without needing to lock the weak_ptr. (If they have shared ownership can you assume the object is still alive and it's safe to compare pointer addresses?) However, now that you highlight the two separate meanings I see that my assumed implementation would be even more confusing than the possible ambiguity with the existing operators. BTW: I meant no offense from non-authoritative, just that I couldn't find that information in the boost documentation. I think I'll keep the shared_ptr != weak_ptr.lock() and move on. Thanks, Matt