From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-02-11 10:10:58
--- In boost_at_y..., Darin Adler <darin_at_b...> wrote:
> On 2/10/02 4:26 PM, "Wyss, Felix" <felixw_at_i...> wrote:
>
> >> Yes, you are right. Keeping a weak_ptr in thread A while all
shared_ptr
> >> owners are in thread B is asking for trouble. This is an
inherent property
> >> of weak_ptr (and any non-owning pointer in general, starting
with raw
> >> pointers) and cannot be fixed.
> >
> > This can be fixed by providing a way to obtain a strong pointer
from the weak
> > pointer. Instead of the get() method, I suggest providing a
strong() method
> > which returns a shared_ptr.
>
> Or maybe even an implicit conversion from weak_ptr to shared_ptr.
>
> Unfortunately, making a thread-safe implementation of this
conversion
> operation is non-trivial, more complex than the thread safety
that's already
> in shared_ptr. Peter Dimov can explain why; maybe we can get him to
explain
> in this thread.
I'm unconvinced that weak_ptr<> is useful in a MT program. At least
not if ANY of the pointers (shared_ptr<> or weak_ptr<>) are shared
across thread boundaries. In this case the weak_ptr<> can't report a
deleted object in any way that's useful.
weak_ptr<foo> pw(ps);
...
if (pw != 0) {
// pw == 0 is possible here!!
}
A redesign might help. If the weak_ptr<>'s only functionality was
conversion to a shared_ptr<> where you'd get a NULL shared_ptr<> if
the object were gone, you wouldn't have the above problem. However,
it wouldn't be efficient either (and would be danged difficult to
implement).
Bill Kempf