2011/11/11 Tim Musson
After re-reading your reply, I think your confusion comes from the following idea: "I still have weak_ptr<> which has a counter ". A line from the weat_ptr<> documentation states that "When the last shared_ptr to the object goes away and the object is deleted, the attempt to obtain a shared_ptr from the weak_ptr instances that refer to the deleted object will fail". So, weak_ptr does not have a counter, that's it's weakness ;)
I don't think I am the one that is confused. When last shared_ptr<> goes out of scope, weak_ptrs know that original object has expired - that is its purpose and its strength not a weakness. It knows that it has expired (has refcount == 0) because it still has access to the counter. It knows it is zero, it knows object has been deleted. Counter is not deleted as long as any weak_ptr<> exist (weakcount > 0) otherwise every weak_ptr<> would be useless after last shared_ptr<> been destroyed. To clarify: weak_ptr<> does not increase/decrease refcount and does not affect object lifetime but it does affect weakcount and counter's lifetime.
I assume that clears things up for you.
ditto Security concerns make little sense for me. Calling get() to obtain raw pointer is as dangerous with weak_ptr<> as with any other smart pointer. Moreover, auto/scoped/unique_ptr can be reset() (or moved) from other thread and screw things up as easily and no one complains. On the second thought on weak_ptr's rationale with regards of thread-safety, what about this: if (!weak.expired()) { // here it can expire from other thread weak.lock()->thisWillCauseAssert(); } Isn't this how weak_ptr<> is suppose to be used? /Simon