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

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

...

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