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: Thorsten Ottosen (thorsten.ottosen_at_[hidden])
Date: 2013-10-03 10:23:30

On 03-10-2013 14:47, Jeff Flinn wrote:
> On 10/3/2013 7:26 AM, Thorsten Ottosen wrote:

>>> is that you do not pass a null pointer. The throw version's precondition
>>> does not include that constraint at all -- instead, you've made
>>> passing a
>>> null pointer acceptable, with the behavior being that an exception is
>>> thrown in the case that such a pointer is passed.
>>
>>
>> So?
>
> So you would never get a failing postcondition without having first
> violated the precondition. Any thing after a violated precondition is
> suspect. So just assert, IMHO.

It's two different guarantees, I guess. Compared to allocating somthing 
on the heap, the runtime check for null is cheap.

If I see a class called non_null_ptr, I pretty much expect it not to be 
null (it's an /invariant/), and use it assuming this. How many other 
classes allow you
to construct an illegal object (an object where the invariant is 
broken?). I can't give any example from Boost or the standard library.

Anyway, we don't have to agree. That's why I suggested a way out, like 
one can do with the pointer containers.

-Thorsten