Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at