Re: [boost] Looking for thoughts on a new smart pointer: shared_ptr_nonnull

Subject: Re: [boost] Looking for thoughts on a new smart pointer: shared_ptr_nonnull
From: Daniel James (daniel_at_[hidden])
Date: 2013-10-07 17:39:33

On 6 October 2013 12:04, Rob Stewart <robertstewart_at_[hidden]> wrote:
>
> If the exception is triggered by an unknown condition, such as you're advocating, then there can be no handler for it. It must, of necessity, unwind to the top. Code cannot rightly continue as if there had been no exception. In that case, there's little gained over an assertion, save for the possibility that other threads may be able to complete independent work.

later:

> The likely outcome of failure in this regard, in a non-debug build, is a null pointer dereference elsewhere. Unchecked, that means a segfault. IOW, the problem will be found.

So you're saying that when it's an exception, it's triggered by an
"unknown condition" not by a null, which is surely a known condition.
But when there's no check it's known to be a null pointer that will be
quickly dereferenced before anything bad might happen. Even if it's in
a data structure, or in a container after hundreds of pointers which
aren't null.

And you're claiming that after an exception the code will continue as
if there was no exception. Is that really what you do after catching
an exception? But when there's no check, it will do the right thing
and continue, which is course as if there was no exception, because
there wasn't one. But that's okay now for some reason.

Do you see why I don't find your argument persuasive?

> The point of the proposed class is that, once (properly) instantiated, it's a signal to code that a null check is unnecessary, just as using a value or reference is.

No it isn't. The description was, "a variation on shared_ptr which is
never allowed to be empty".