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-05 10:09:33

On 4 October 2013 23:09, Matt Calabrese <rivorus_at_[hidden]> wrote:
> 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

I don't want any preprocessor switches, I want predictable behaviour.
If you don't want a null check, use shared_ptr, not a class which is
intended to prevent nulls.

Preprocessor switches tend to cause more problems than they solve. For
a relevant example, see https://svn.boost.org/trac/boost/ticket/7028
There's confusion about what the switches do, there's inconsistencies
in what they do, there are subtle issues in implementing them in a
consistent manner, and to top it all, it still hasn't been resolved.

> but ultimately this is an
> error that cannot be handled once such a condition is reached. You cannot
> reliably continue.

I've already given a counter-example to that. If your data is well
encapsulated, an unexpected null is not an indicator of a problem in
the global state.

> 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

This class is meant to make code safer - that is its point. But as you
describe it, just using this class introduces the possibility of
undefined behaviour where there was none before. And undefined
behaviour can do anything. So it actually makes code less safe. So why
use the class?

> since this either A) throws an exception that cannot be
> properly handled

You keep saying that, but you never justify it. This kind of thing is
very contextual, there are no universal laws.

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

You have faith that programmers won't violate your pre-conditions, but
you don't have faith in them following your theories about exceptions.
Which is odd since the latter is easier to do, and less problematic if
it isn't followed.