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: Mostafa (mostafa_working_away_at_[hidden])
Date: 2013-10-02 13:47:33

On Wed, 02 Oct 2013 05:52:48 -0700, Jeff Flinn <jeffrey.flinn_at_[hidden]>  
wrote:

> On 10/2/2013 7:18 AM, Luke Bradford wrote:
>> 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.
>
> Keeping bool conversion allows your ptr type to be used with templated  
> code that may do the checks, which would otherwise be complicated by the  
> divergence from pointer semantics. Perhaps marking the operator  
> constexpr would allow the compiler to optimize away any branches.

Why not cast to whatever smart ptr type the template code already expects?  
The whole point of smart_ptr_nonnull is to clearly convey that an obj of  
such a class cannot ever be null, and IMO the bool conversion operator  
defeats that purpose.