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: Matt Calabrese (rivorus_at_[hidden])
Date: 2013-10-04 18:09:45

On Fri, Oct 4, 2013 at 1:09 PM, Daniel James <daniel_at_[hidden]> wrote:

> If throwing an exception when this is null is a bad idea, then not
> checking in release mode is surely a terrible one.

If you want some kind of a preprocessor switch for terminating on null or
just leaving it strictly UB, I think that's fine, but ultimately this is an
error that cannot be handled once such a condition is reached. You cannot
reliably continue. All I'm saying is what Eric is reiterating -- it's a
precondition violation, which is UB, so just use an assertion given that
this particular precondition is easily able to be checked. Further, I vote
against removing it as a precondition/turning it into documented
exception-on-null, since this either A) throws an exception that cannot be
properly handled, or B) invites users to rely on the exception behavior to
use the exception for control flow (I.E. instead of checking for null
before handing it off, they pass it off and check for null by catching an
exception, which is a misuse of exceptions). I can maybe see some kind of a
preprocessor hook here that users can use to force terminates in release
beuilds or do logging or something, but ultimately we're dealing with UB no
matter how you look at it and I feel that an assert is proper and also the
simplest approach.

If the type could be designed to somehow avoid the possibility entirely
(i.e. via make_ functions), that's obviously the best way to go, but going
back to my pointer-from-factory example, you ultimately still need some
kind of raw method of construction unless you completely sacrifice a common
use-case. One final approach, though one I don't really recommend, is that
you could always make the raw version take a reference instead of a
pointer. This side-steps the issue since it means that any corresponding UB
was triggered before the function was called. Now your constructor has no
non-null precondition and from the constructor's point of view the
reference can't be null, so there's no reason to check.

Again, I don't really advocate that, I'm just pointing it out as a possible
course of action.

-- 
-Matt Calabrese