|
Boost Users : |
From: Matt.Sullivan_at_[hidden]
Date: 2006-09-25 21:02:38
Peter Dimov <pdimov_at_[hidden]> wrote on 26/09/2006 02:49:10 AM:
> 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;
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
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net