Re: Usefulness of weak_ptr

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