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

On 4 October 2013 23:09, Matt Calabrese wrote:

On Fri, Oct 4, 2013 at 1:09 PM, Daniel James 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.