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: Nevin Liber (nevin_at_[hidden])
Date: 2013-10-10 18:50:19

On 10 October 2013 17:12, Gavin Lambert <gavinl_at_[hidden]> wrote:

> On 10/11/2013 4:00 AM, Quoth Nevin Liber:
>
>  In general, destructors are written assuming the invariants of the class
>> hold on entry to the destructor.
>>
>
> And..?  If the constructor of an object throws, its destructor is not
> invoked.  So all destructors that are called should still have good
> invariants.
>

If everything is good, where did the bad null pointer come from??  More
likely than not it is due to another (undetected) broken invariant.

It's only if you *don't* throw from the constructor that you'll have a
> problem, because now you *do* have an object with an invalid invariant.

It is up to the designer of the library to determine if passing parameters
that make it impossible to set up the class invariant is reasonable or
not.  If it is reasonable, it is part of the contract, and no problem.

>
>  In order for what you say about stack unwinding to be true, you have to
>> assume that the null pointer isn't due to a broken invariant somewhere
>> else.  Where is your evidence that no other object or program invariants
>> are broken?
>>
>
> Where is your evidence that they are?
>

The fact that a programming bug was detected is strong evidence that
something is, in fact, broken.

> Given that this must (by definition) be the first time that this
> particular pointer has been assigned to a "must be non null" smart pointer
> object, everything else higher up the call stack either must not be using
> the pointer or must be ok with the idea that it could be null, otherwise
> the problem would have been encountered earlier.

If it was okay with it being null, why did it pass it to the non-null smart
pointer?  It may have hit other undefined behavior much earlier than this.
Like I said, you've detected a programming bug, but you have no idea how
extensive the damage already is.  Pretending there is no other damage is
lousy risk analysis.

>
>
>  Data corruption is a far worse user experience.
>>
>
> Granted.  But there shouldn't be any of that here, unless the programmer
> doesn't write their higher-level catch handler properly.
>

Could you please show us your universal catch handler that handles every
possible programming error w/o aborting, including corruption that might
happen during the stack unwinding?
-- 
 Nevin ":-)" Liber  <mailto:nevin_at_[hidden]>  [phone]