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-04 04:56:48

On 03-10-2013 22:01, Matt Calabrese wrote:
> On Thu, Oct 3, 2013 at 8:59 AM, Thorsten Ottosen <
> thorsten.ottosen_at_[hidden]> wrote:
>
>> I can't create a broken std::vector by means of the constructor. At least
>> I don't know how to. WhenI think about it, std::string can crash if you
>> pass it null_ptr. Has anybody profitted from that? It leads to
>> subtle run-time bugs, and I ran into that a few months back.
>
>
> I think it's just clear that we have some ideological differences here.
> std::string should not be checking for null as a part of its documented
> functionality.

I think you misunderstood. The std::string constructor that takes a 
const char* cannot be passed NULL. Then add the fact that the string 
constructors are not explicit. Then add overloads into the mix, some 
with string, some with ints.

I'm not a big fan of defensive programming, but the world of programming 
is complicated, and sometimes it makes sense to be a little defensive.

>
>>> You forget that some people prefer to provide a nice log message and warn
>> the users in a nice way instead of crashing the program.
>>
>
> If it's decided that that is what's important, then that's fine.
>

I guess it is important to some, and not to others. The thing is, even 
with 100% test coverage, we can't guarantee that some code won't contain 
an invalid non_null_shared_ptr at runtime at a customer.
Yes, there is a bug in one part of the program, but it certainly matter 
for us that we don't have to take down the whole program, but can 
continue gracefully.

-Thorsten