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: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2013-10-02 07:40:11

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? 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,
except that the referred object is accessed through operator->. Maybe
it should be called shared_ref because of it. Thinking about it this
way, there is no need for reset() or constructors from pointers - only
assignment, emplace() and forwarding constructors. Interoperability
with shared_ptr can be provided as an extension (maybe with free
functions), but that would be just an extension, i.e. no implicit
conversion.