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: Thorsten Ottosen (thorsten.ottosen_at_[hidden])
Date: 2013-10-08 08:00:52

On 08-10-2013 00:43, Gavin Lambert wrote:
> On 10/7/2013 10:48 PM, Quoth Thorsten Ottosen:
>> If the idea is to be 100% shared_ptr interface compatible, it may be
>> easier just to extend boost::shared_ptr a little:
>>
>>    typedef boost::shared_ptr<boost::non_nullable<T>> SharedT;
>
> I don't like that.
>
> If you're suggesting using a wrapper type without changing shared_ptr,
> that won't work because the shared_ptr itself could still be empty, so
> you haven't gained anything.

I'm not.

> If you're suggesting specialising shared_ptr for that subtype, I don't
> see any benefit in doing this over defining a new pointer type, since
> you have to redefine everything in a specialisation anyway.

I'm not.

> And there's undoubtedly some existing templated code that operates on
> boost::shared_ptr<T> that would be confused by this,

Well, wouldn't that code use shared_ptr<T>::element_type?

> or at the very
> least not operate efficiently by including tests for null.

I'm confused. What tests?

Anyway, in Boost.PtrContainer you can change the "null behavior" by saying

    ptr_vector<T>           vec_non_nulls;
    ptr_vector<nullable<T>> vec_with_nulls;

The shared_ptr implementation would have to check its template argument	
and emit special code in a few places. This is very easy to do, and far 
easier than specializing/wrapping the class.

>> typedef boost::shared_ptr<boost::non_nullable<T>> WeakT;
>
> I assume that was a typo.  (Weak pointers are not especially useful
> without being able to represent null anyway.)

Yes, sorry, a typo.
I suppose there is still a need to break cycles. Why would this have 
changed.

-Thorsten