Re: [Boost-users] intrusive_ptr vs shared-ptr
Well I wouldnt say these items are 'marginal', because most come from real life scenarios. You can work around things but it is always that u have to remember that there were some boundary cases with shared_ptr. It took me some time to convince my colleagues to swap from raw pointers to shared pointers and having some boundary cases doesn't help then. I still prefer shared pointers, but I am not sure if all in all they would be better than e.g. intrusive_ptr's with ref counting (even without lacking the weak_ptr feature). Note that i look upon this from a client perspective (i.e. large data acquisition application), not from a library builder perspective.
I really miss having a "lost and found" feature, which (in the late 90's) I wrote about as being one of the six essential features of my smart pointer design. That is, given a raw pointer p that is already known to the smart pointer system, creating another smart pointer from p will work in harmony with them, NOT break it. I've repeatedly come across code that hooks up objects with other objects in the constructor and I've had to work-around that in various ways, usually by adding a Create wrapper that finishes the work, and sometimes fiddling more than I would have wanted to with the design. I've also found cases where it is really annoying not knowing whether another smart pointer has already been created yet for the object. Anyway, for intrusive smart pointers, the "lost and found" feature is very easy and efficient to implement. So perhaps it should be part of Boost intrusive_ptr as an extension to the standard, or another class can be added with a different feature set. Anyway, if you want a class like that, feel free to grab my old code from the "Classics" or "Repertoire" project parked on github. —John
On Tue, Jan 22, 2013 at 3:46 AM, John M. Dlugosz
I really miss having a "lost and found" feature, which (in the late 90's) I wrote about as being one of the six essential features of my smart pointer design.
Yes, I was wondering if the magic call inside of smart_ptr's constructor, that handles the enabled_shared_from_this, wouldn't be better as a free function, like smart_pointer_being_created(), which gives you an extension point to go look up whether the object already had a smart pointer. It could default back to the enabled_shared_from_this trick if you don't override it for your types, etc. Qt's smart pointer has extra tracking like this - typically only turned on in debugging. Tony
On 1/22/2013 3:46 AM, John M. Dlugosz wrote:
Well I wouldnt say these items are 'marginal', because most come from real life scenarios. You can work around things but it is always that u have to remember that there were some boundary cases with shared_ptr. It took me some time to convince my colleagues to swap from raw pointers to shared pointers and having some boundary cases doesn't help then. I still prefer shared pointers, but I am not sure if all in all they would be better than e.g. intrusive_ptr's with ref counting (even without lacking the weak_ptr feature). Note that i look upon this from a client perspective (i.e. large data acquisition application), not from a library builder perspective.
I really miss having a "lost and found" feature, which (in the late 90's) I wrote about as being one of the six essential features of my smart pointer design. That is, given a raw pointer p that is already known to the smart pointer system, creating another smart pointer from p will work in harmony with them, NOT break it. I've repeatedly come across code that hooks up objects with other objects in the constructor and I've had to work-around that in various ways, usually by adding a Create wrapper that finishes the work, and sometimes fiddling more than I would have wanted to with the design. I've also found cases where it is really annoying not knowing whether another smart pointer has already been created yet for the object.
The way I found to do this is to have an object created through a smart pointer participate in a two-phase creation process. The first phase is some constructor and the second phase is some sort of initialization member function, which I usually call Init of the form 'void Init()'. In the Init member function, use shared_from_this() to create a weak_ptr to the object's smart pointer as a private member data variable. Then add a member function, which I usually call ToPtr, which returns the object as a smart pointer using the private member data function by calling Lock on the weaK_ptr. Now if you have a raw pointer to the object you can call it's ToPtr member function to get its smart pointer. You need the two-phase creation process because you cannot use shared_from_this() until the object is fully constructed. I do not know how closely this mimics your "lost and found" feature but it enables you to get a smart pointer from a raw pointer of the same type. Of course your object must always intially be created as a smart pointer, which means it must always be dynamically allocated.
participants (3)
-
Edward Diener -
Gottlob Frege -
John M. Dlugosz