Boost logo

Boost :

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
> >> 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
> 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
> 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

Bill Kempf

Boost list run by bdawes at, gregod at, cpdaniel at, john at