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: Rob Stewart (robertstewart_at_[hidden])
Date: 2013-10-05 06:18:35

On Oct 4, 2013, at 1:38 PM, Matt Calabrese <rivorus_at_[hidden]> wrote:

> Almost all of these cases can be handled by named constructor-like functions in a somewhat elegant manner, with the exception perhaps of the last one (what happens if the factory function can return a null pointer? We're back to the original issue, in that case, only worse because the programmer cannot simply handle that case outside of the constructor). I
> think ultimately my vote would be to support named functions, but there still needs to be a way to do construction via a direct pointer otherwise we are losing functionality that shared_ptr provides.

The factory/named constructor functions can throw, or not, as the case warrants. They can be viewed as conveniences for using the class. The constructor could be public and assert on null pointer, while the factories can offer other policies.

> I'll repeat my basic, underlying stance here for people to agree/disagree with. A non-null shared_ptr should be exactly that. It should have the same
> or extremely similar interface to a shared_ptr (including things like bool-conversion), just with more strict invariants and preconditions. This makes drop-in replacement and use in generic functions easier to deal with and also avoids sacrificing additional functionality that shared_ptr provides. People shouldn't have to avoid switching to a non-null shared
> pointer simply because they have no way of constructing it with a pointer that they obtained from a factory.

+1

___
Rob

(Sent from my portable computation engine)