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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk