Re: [boost] Looking for thoughts on a new smart pointer: shared_ptr_nonnull

On 9 October 2013 10:43, Rob Stewart wrote:

On Oct 8, 2013, at 2:37 PM, Daniel James wrote:

...

On 6 October 2013 19:14, Matt Calabrese wrote:

...

On Sun, Oct 6, 2013 at 2:11 AM, Daniel James 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.