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 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.