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: Matt Calabrese (rivorus_at_[hidden])
Date: 2013-10-04 12:20:50

On Fri, Oct 4, 2013 at 1:56 AM, Thorsten Ottosen <
thorsten.ottosen_at_[hidden]> wrote:

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

Yeah, I do agree with some of this. I agree with the standard not doing
explicit null checking for the constructor as a part of the documented
functionality. I do not, however, agree with the constructor being
implicit, so I'm with you there.

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

Understood.

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.

Yeah, I do see the other side of this -- there is perhaps a middleground
here that I think I'm more okay with than throwing an exception, and that
is to do something like terminate, maybe even based on a preprocessor
switch as to whether you terminate or simply leave it as UB (that way you
can still at least avoid proceeding in a release build without introducing
an exception that people could "handle"). If I'm alone on this during
review, assuming it gets there, it's not something I'd really put up a
stink about, but I definitely am against an exception for this type of
programmer error.

-- 
-Matt Calabrese