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: Luke Bradford (lukebradford01_at_[hidden])
Date: 2013-10-02 07:18:08

Thanks for the feedback, Matt - some quick thoughts:

> Not having a default constructor seems unnecessary to me. Why not just
have
> the default constructor dynamically allocate a default constructed object?
> Similarly, for consistency with other smart pointers, having a conversion
> to bool would be useful and makes transition to the type simpler.

Often the object pointed to will not have a default constructor, so we
wouldn't be able to construct one in shared_ptr_nonnull's default
constructor. I also think that having a conversion to bool is misleading -
in the use cases I've seen, it would lead to a lot of extraneous if( ptr )
statements, then essentially if( true ), which obscure the programmer's
intentions and are easy to remove. I found the elimination of the default
constructor and conversion to bool just as useful, if not more useful, than
the runtime checks of the class, because they revealed places where we were
default constructing or checking a shared_ptr that we expected to be valid
at all times.

> I don't think an exception here is proper. Initializing the object by
> passing a null pointer should be UB since it is a clear violation of the
> constructor's assumed precondition (don't pass a null pointer), and
similar
> for other operations that would produce such a "null" non-null object.
> Rather, these should simply be asserts.

I could go either way on this one. One reason I opted for throwing is
because that's the behavior of shared_ptr when you construct it with an
empty weak_ptr, and this seemed like a similar situation.

> I'm fine with this except for the implicitly convertible to shared_ptr
> part. What's wrong with explicit conversion here?

I like the implicit conversion for convenience in using the class in place
of shared_ptr. Is there a reason you wouldn't want to have implicit
conversion?

Thanks,

Luke

On Wed, Oct 2, 2013 at 12:37 AM, Matt Calabrese <rivorus_at_[hidden]> wrote:

> I agree that non-null smart pointers are a useful facility. That said I do
> have some additional thoughts:
>
> On Tue, Oct 1, 2013 at 3:54 PM, Luke Bradford <lukebradford01_at_[hidden]
> >wrote:
>
> > (1) It doesn't have reset() with no arguments, doesn't have a default
> > constructor, and doesn't have implicit conversion to bool (which would
> > always be true.)
> >
>
> Not having a default constructor seems unnecessary to me. Why not just have
> the default constructor dynamically allocate a default constructed object?
> Similarly, for consistency with other smart pointers, having a conversion
> to bool would be useful and makes transition to the type simpler. IMO we
> should keep a similar interface where possible, even if the result is
> statically known.
>
> (2) It throws an exception whenever there's an attempt to make it empty,
> > i.e. in constructors, reset, assignment, and swap.
> >
>
> I don't think an exception here is proper. Initializing the object by
> passing a null pointer should be UB since it is a clear violation of the
> constructor's assumed precondition (don't pass a null pointer), and similar
> for other operations that would produce such a "null" non-null object.
> Rather, these should simply be asserts.
>
> For convenience, it's implicitly convertible to shared_ptr, and I have all
> > of shared_ptr's templated operators implemented with possible
> combinations
> > of shared_ptr and shared_ptr_nonnull. Usually it can be used just by
> > changing the type of a shared_ptr.
> >
>
> I'm fine with this except for the implicitly convertible to shared_ptr
> part. What's wrong with explicit conversion here?
>
> --
> -Matt Calabrese
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>