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: Daniel James (daniel_at_[hidden])
Date: 2013-10-09 18:49:28

On 9 October 2013 10:43, Rob Stewart <robertstewart_at_[hidden]> wrote:
> On Oct 8, 2013, at 2:37 PM, Daniel James <daniel_at_[hidden]> wrote:
>
>> On 6 October 2013 19:14, Matt Calabrese <rivorus_at_[hidden]> wrote:
>>> On Sun, Oct 6, 2013 at 2:11 AM, Daniel James <daniel_at_[hidden]> wrote:
>>>
>>>> How is that not introducing undefined behaviour? Say there's a function:
>>>
>>>> void foo(boost::shared_ptr<...> const& x) {
>>>>    if (!x) { something_or_other(); }
>>>>    else blah_blah(*x);
>>>> }
>>>>
>>>> By using shared_ptr_nonull, that check can be removed:
>>>>
>>>> void foo(boost::shared_ptr_nonnull<...> const& x) {
>>>>    blah_blah(*x);
>>>> }
>>>>
>>>> But then a caller believes that their shared_ptr is never null, so they copy it into a shared_ptr_nonnull without checking for null first, and that action introduces the possibility of undefined
>>>> behaviour where there was none before (given that there's always a possibility of bugs in non-trivial code).
>>
>> No response to this example?
>
> Why does the author of foo() know enough to test for null, but the caller of foo(), knowing that they are creating a shared_ptr_nonnull, doesn't?

I better explain this, it's easier because foo is only defined once
with the assumption that the pointer can be null because it really
doesn't know where the pointer came from. But there can be a large
number of calls, so when changing foo every call would need to be
altered. The dangerous part is when altering the code the programmer
may make assumptions because they think they know where the pointer is
coming from at the call site. Often they actually do, but sometimes
mistakes are made, and the more places the more likelihood of a
mistake. Generally speaking, such defensive programming shouldn't be
scattered all over the place.