On 2/5/2013 9:43 AM, boost-users-request-at-lists.boost.org |Boost/Allow to home| wrote: From: Dominique Devienne<ddevienne@gmail.com>
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 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