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: Bjørn Roald (bjorn_at_[hidden])
Date: 2013-10-02 13:11:01

On 10/02/2013 01:40 PM, Andrey Semashev wrote:
> On Wed, Oct 2, 2013 at 2:54 AM, Luke Bradford <lukebradford01_at_[hidden]> wrote:
>> Hi,
>>
>> I'm new to this list, so apologies for any oversights or faux pas.
>>
>> I've been finding a lot of use for a type of smart pointer I call
>> shared_ptr_nonnull, which is a variation on shared_ptr which is never
>> allowed to be empty. Specifically:
>>
>> (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.)
>> (2) It throws an exception whenever there's an attempt to make it empty,
>> i.e. in constructors, reset, assignment, and swap.
>>
>> 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.
>>
>> We have a lot of shared_ptrs, especially member variables, which are
>> claimed to be "always valid" and this class enforces that, at compile time
>> (1) and runtime (2).
>>
>> Has there been any discussion of something like this? Does anybody have any
>> thoughts, suggestions, criticisms?

This is an interesting idea, but I am not sure how much I would need or 
use such a class template.  How do you intend to break cycles?  Do we 
new the weak_ptr_nonull variant as well, or are cycles impossible?

>> Who's in charge of the smart pointer
>> library these days?
>
> This may be useful, although I don't remember needing such a tool in
> my practice. Somehow it's usually enough for me to simply copy or move
> objects or have them implemented as shared pimpl using shared_ptr or
> intrusive_ptr internally. In the latter case the pointer
> initialization is very well isolated, so there is no problem with NULL
> pointers.
>
> Anyway, I think, such a pointer does not behave like a real pointer,
> so it shouldn't be called as such. It looks more like a reference,

+1

> except that the referred object is accessed through operator->.

Yes,

> Maybe
> it should be called shared_ref because of it.

+1
too bad there is no overladable operator.() as alternative to 
operator->, but that would maybe break more generic code than desired.

-- 
Bjørn