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

On 10/02/2013 01:40 PM, Andrey Semashev wrote:

On Wed, Oct 2, 2013 at 2:54 AM, Luke Bradford 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