[smart_ptr] comparison operators: shared_ptr == weak_ptr?
Hi, Probably a newbie question, but what's the best way to test if a shared_ptr and weak_ptr point to the same thing? My current code uses: if (shared_ptr != weak_ptr.lock()) but it feels wrong to create a temporary with some small locking overhead - even though I realise it will make absolutely no difference to performance. So, my question is really why is there no operator==(shared_ptr, weak_ptr)? Google provided little explanation other than this: http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2004/n1590.html which approaches the subject but isn't exactly authoritative. thanks, Matt
On 9/25/06, Matt.Sullivan@leica-geosystems.com < Matt.Sullivan@leica-geosystems.com> wrote:
Probably a newbie question, but what's the best way to test if a shared_ptr and weak_ptr point to the same thing?
My current code uses: if (shared_ptr != weak_ptr.lock())
I don't know for sure, but can't you convert the shard_ptr to a weak_ptr and write this: if( weak_ptr(shared_ptr) != weak_ptr ) Phillip
Phillip Hellewell
I don't know for sure, but can't you convert the shard_ptr to a weak_ptr and write this: if( weak_ptr(shared_ptr) != weak_ptr )
No, there aren't any weak_ptr == or != operators either. I could write: weak_ptr temp(shared_ptr); if ( !(temp < weak_ptr) && !(weak_ptr < temp)) to test for weak_ptr ownership equivalency, but I think I'll just stick to the weak_ptr.lock(). thanks, Matt
Matt.Sullivan@leica-geosystems.com wrote:
Hi,
Probably a newbie question, but what's the best way to test if a shared_ptr and weak_ptr point to the same thing?
My current code uses: if (shared_ptr != weak_ptr.lock()) but it feels wrong to create a temporary with some small locking overhead - even though I realise it will make absolutely no difference to performance.
So, my question is really why is there no operator==(shared_ptr, weak_ptr)?
I can think of three reasons, none of them authoritative: 1. If this operator== ends up doing shared_ptr != weak_ptr.lock() under the 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; and last but not least 3. Nobody suggested the need for such an operator, so it wasn't included.
Google provided little explanation other than this: http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2004/n1590.html which approaches the subject but isn't exactly authoritative.
;-)
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
participants (3)
-
Matt.Sullivan＠leica-geosystems.com -
Peter Dimov -
Phillip Hellewell