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-09 14:58:50

On 9 October 2013 12:13, Cliff Green <cliffg_at_[hidden]> wrote:

>
> First, I'm completely in the camp of "if you define a pre-condition and it
> is violated, don't throw an exception or otherwise change the undefined
> behavior to some sort of different execution path".
>
> One of the arguments for throwing an exception (or related design) for
> logic errors is to aid in bug detection as well as provide a path for
> abnormal error recovery. Both of these are good, real-world considerations,
> but (to me) are separate from the DBC discussions.
>

When I say one should assert on a detected precondition failure, it's
really shorthand for putting the system into a known state.  A mission
critical system, for instance, might do something vastly more complicated
than aborting.

I just don't see how throwing, which normally involves running code
dependent on state, accomplishes this.

Debug builds are a different story, as it is okay not to put the system in
a known state; a deliberate tradeoff is made between that and the time it
takes to set up and search for more bugs, along with the understanding that
some of the subsequent bugs may be either be false positives or hidden due
to continuing in an unknown state.

> (BTW, a non-null pointer might not be a valid pointer - besides checking
> for null, should the library also check that the pointer is within a valid
> process data memory area?)
>

That still isn't enough, as memory corruption due to some other bug may
cause an invalid but non-nullptr pointer.
-- 
 Nevin ":-)" Liber  <mailto:nevin_at_[hidden]>  [phone]