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: Gavin Lambert (gavinl_at_[hidden])
Date: 2013-10-07 01:04:39

Moments ago, quoth I:
> On 10/7/2013 4:37 PM, Quoth Matt Calabrese:
>> If you are violating your precondition, throwing is not a proper solution
>> for the reasons already explained several times at this point. Why the
>> non-nullness of the pointer should be a precondition was also already
>> explained.
>
> I have yet to see anything that convinces me that there is a valid
> reason for that.  Maybe I missed it, or maybe we just don't agree on
> this aspect of code design. :)

Just to try to head off an anticipated objection, I'll requote something 
else you said earlier:

On 10/4/2013 4:04 AM, Quoth Matt Calabrese:
> If you want unraveling of the stack or catching of the exception to
> be worthwhile,then you need to eliminate the precondition
> altogether.

I agree with that.  I just think that it is indeed the correct behaviour 
to eliminate the precondition from the constructor (and replace it with 
defined behaviour to throw, and ideally to also assert).

I don't like the idea of public methods (especially constructors) that 
make assumptions about their external input without testing it.  Input 
can *always* be screwed up, either by user or programmer error.

You can be reasonably confident about your private internal data (that's 
what unit tests are for).  You should still assert on it, of course, 
because compiler/linker weirdness or memory-overwrite damage from bugs 
in other code can get you into a weird state, but that sort of thing 
truly is in UB territory and there isn't much you can do to recover from 
that.