Re: [boost] [interest] rich-typed smart pointers

Subject: Re: [boost] [interest] rich-typed smart pointers
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2013-10-06 20:34:25

On 10/6/2013 8:34 AM, Quoth Julian Gonggrijp:
> As for safety, I think std::weak_ptr is not really safer that rtp::weak_ptr
> because it's just as easy to produce a dangling pointer (in fact std takes
> only 3 lines of code to do it while rtp requires 4) and that's a disaster no
> matter what. The fact that it can detect that it's dangling does however
> make it easier to debug.

I fail to see why "dangling pointers" are a disaster with std::weak_ptr.

Their implementation does not permit any access without locking the 
pointer, which will either succeed (and consequently prevent the object 
from being destroyed while it is being accessed) or fail (if the object 
has already been destroyed) and return a null pointer.

The code using the pointer has to be able to cope gracefully with 
failure to obtain a pointer, but this is built into the semantics of 
weak_ptrs -- if you can't write the code such that it can fail 
gracefully, then you should have been using a shared_ptr instead so that 
you can guarantee that the object won't disappear before you're ready 
for it to do so.

Bare pointers, on the other hand (including rtp::weak_ptr, from what I 
understand from this discussion, though I haven't examined the code 
specifically) have no such tracking/locking capability so there is no 
way to ensure that a particular pointer value still points at the same 
object as it originally did.

Sure, it's still possible to get a null pointer access with 
std::weak_ptr, by locking one and then accessing the resulting 
shared_ptr without checking for validity (ie. lazy programmer).  But in 
this case it will assert, and even failing that null accesses are far 
easier to track down and deal with than non-null-invalid-object accesses.

(I'm not saying that shared_ptrs don't have problems -- for example it's 
far too easy to get into trouble with cyclic references if you're not 
careful, and I've yet to find any good tools to track these down.  But 
they don't have *this* particular problem, since solving that is pretty 
much their entire reason for existing in the first place.)