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: Rob Stewart (robertstewart_at_[hidden])
Date: 2013-10-07 21:09:19

On Oct 7, 2013, at 5:39 PM, Daniel James <daniel_at_[hidden]> wrote:

> 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.

No

> 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.

No

> And you're claiming that after an exception the code will continue as if there was no exception.

No, Pete, I think it was, advocated letting thousands of tasks continue while a few failed.

> Is that really what you do after catching an exception?

No

> 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.

No

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

What I understand is that you've misunderstood me. I'll try again.

If a null pointer occurs somewhere in your code and this class' ctor throws an exception, the handler has no idea of the source of the null pointer. Thus, the you have an unknown condition as far as the handler is concerned. (I had been discussing a handler in main() or a thread procedure, as opposed to one very near the object mis-construction.)

OTOH, if a null is actual stored in the object, then it will eventually be dereferenced, in the general case anyway, and the segfault will indicate which instance was bad. From that you should be able to discover its genesis, at least if the object's address is consistent or the pointee's type is unique. That makes finding the source of the null pointer somewhat more tractable without a debugger.

In both cases, you can introduce code to trace or log the inputs or exceptions, so neither is necessarily better for that.

>> 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".

That's an important distinction that I overlooked, but it doesn't affect my position: non-null raw pointer is a precondition of the ctor and should be asserted, but factory functions can throw for those that don't want to code the conditionals when a pointer isn't known to be non-null. (Consider the case of taking the address of a static object. There's no need to check for null, so there's no need to risk pipeline stalling on a failed branch prediction or cache invalidation due to the exception construction and throwing code you'd add to the ctor otherwise.

___
Rob

(Sent from my portable computation engine)