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: Julian Gonggrijp (j.gonggrijp_at_[hidden])
Date: 2013-10-07 19:16:07

Gavin Lambert wrote:

> On 10/7/2013 11:47 PM, Quoth Julian Gonggrijp:
>> While I'm not Matt Calabrese, I think I can restate why it should be a
>> precondition *especially* on the constructor. The entire point of the
>> proposed non-null pointers is to guarantee that the pointer is not
>> null, so that receiving functions and storing objects can assume that
>> it is not null. If you zero-initialize a pointer whose very purpose is
>> not to be null, you defeat the purpose of its existence.
> 
> This sounds to me like an argument *for* the position I am suggesting, not against it.
> 
> Throwing an exception means that the internal bare pointer is never initialised to null (or at least that if it is initialised to null, it can never be accessed as such because the resulting object is not retained), which means that it will never be accessed in an undefined way.
> 
> If you fail to throw the exception (and to assert, because you're in a release build) then you *do* go on to set the bare pointer to null, and *the program does not immediately fail*.  By contrast, it will fail at some unknown later point at which someone actually attempts to access the pointer.  If you're lucky, that's in the following line, and the bug is easier to find.  If you're unlucky, it's three hours later (because the pointer was created as a member field in another object that is only accessed rarely) and it's much harder to figure out what happened.
> 
> Checking in the constructor is instant and failsafe.  Not checking is just leaving a time bomb in the code.
> 
> [...]

I'm sorry to say this, but I think you're now just being evasive. A
few posts ago in a reply to Matt, you stated that you agreed that if
the assertion is to be replaced by a throw, the precondition should be
removed from the constructor. This means that you also agree that if
the precondition is *not* removed from the constructor, the assertion
should *not* be replaced by a throw (modus tollens).

You then argued that the precondition should indeed be removed because
you find that the check is important enough to not remove it in
release builds. You challenged Matt to give you a reason why the
precondition should be preserved. Matt has explained why it should
remain a precondition and I have restated in my own words why it
should.

My argument was not about whether the condition is important enough to
check in a release build. I was stating why it should be a
precondition. You did however not react to the content of my argument;
instead, you coerced it into an argument on why the condition should
be checked. You have not evaluated whether you agree that it should be
a precondition.

In this way we cannot make progress. Either you agree that the
condition should be a precondition, or you don't but then you should
join the discussion on what's the purpose of the non-null pointer and
on what's the responsibility of the programmer.

I don't think that anyone disagrees that in the ideal world, all
conditions are always checked. Apparently we also agree that checks on
preconditions should be assertions when a check is at all possible. So
the discussion should be about whether not passing null to the
constructor is a precondition.

-Julian