Thanks for any insight on this. Could very well be I'm missing
something obvious (my C++ expertise doesn't rise to Boost levels), but
so far I fail to see the drawbacks.
My old smart pointers (dating back to the '90's) had full support for initializing a smart
On 2/5/2013 9:43 AM, boost-users-request-at-lists.boost.org |Boost/Allow to home| wrote:
From: Dominique Devienne
pointer from a raw pointer even if it was already known to the smart pointer system. It
was one of six _essential_ features (I called it “lost and found”) and I agree there were
no troubles with it. It is easy to do when the class is derived from a helper base (like
enable_shared_from_this does) and furthermore it doesn't need the CRTP.
I agree that an extension to the now-standard enable_self_from_this could be implemented
that gives a self_from_this that may be called during the constructor or as the first way
to obtain a shared_ptr, also provide for "lost and found" usage, and not behave
differently for any usage that is well-formed using the standard class (that is, it would
be a pure extension).
When changing some existing code to use shared_ptr, I've wished something like that was
available, and missed my old class in this respect. For new code, in general use a Create
static member that wraps the call to the (private) constructor so you can't create
anything other than a shared_ptr, and the stuff that needs the shared ptr during
"construction" gets moved to the stage 2, in the body of Create. In particular, if the
object registers itself with collaborators (via shared pointers) you really wanted that
part _in_ the constructor.
—John
