|
Boost : |
From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-02-09 06:27:16
From: "Joe Gottman" <joegottman_at_[hidden]>
> I can see this, but there seem to be a few dangers. For instance, it
> would be very dangerous to keep a set of weak_ptr's. If the underlying
> object of a weak_ptr were deleted, then the weak_ptr's get() suddenly
> returns a 0. This will almost certainly mess up the set's invariant that
> its members are stored in some sorted order.
Well spotted, thanks. I'll fix it.
> Also, I think weak_ptr is inherently thread-unsafe.
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.
> For instance, its
> get() function is implemented as follows:
>
> T * get() const // never throws
> {
> return use_count() == 0? 0: px;
> }
No matter how you implement get(), it will still have the same problem.
weak_ptr is just a tiny bit above a raw pointer in the food chain.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk