On 7 October 2013 14:34, Julian Gonggrijp wrote:
Jonathan Wakely wrote:
On 7 October 2013 11:01, Julian Gonggrijp wrote:
The std::weak_ptr detects the dangling pointer and changes it into a null pointer. This makes sense, because null pointers are easier to detect. However, as the surrounding code probably relies on a live pointer (because dangling pointers are never planned) the program is still going to fail. This is what I meant by "disaster".
Why is it going to fail? Expired pointers (not dangling ones) most certainly are planned, and weak_ptr is designed to support (and detect) that case. Users of std::weak_ptr know that it needs to be checked, and the explicit conversion that is needed makes it hard to forget to do that. Either you say:
std::shared_ptr<X> sp(wp);
which will throw if weak_ptr.expired() is true, or you use the non-throwing form in a conditional:
if (auto sp = wp.lock()) /* ... */ ; else /* deal with it */ ;
Of course a programmer can avoid the problem by doing the right thing. That's not what my paragraph above was about. As I stated in the follow-up, the same reasoning applies to the rtp pointers.
Does it? How do I tell if an rtp::weak_ptr is dangling or not? You seem to be claiming that because sloppy programmers can forget to check a std::weak_ptr for validity that it's no safer than a type that doesn't even support such checking for validity. I say screw the sloppy programmers, the type that supports checking is safer than one that doesn't. With std::weak_ptr I can write my code to allow expired pointers and handle them correctly, but IIUC with the rtp (soon-to-be-renamed) weak_ptr I just have to "do the right thing" to avoid the possibility of expired pointers.