Why doesn't shared_ptr have a virtual descructor? (and how can I get around this?)

Question

I wanted to make a special version of shared_ptr that would perform specific operations when it was created or destroyed, but my plans appear to be foiled by the realization that shared_ptr's destructor is non virtual, meaning when I override it, my pointers never get cleaned up when the last instance of them are destroyed.

The only alternative that comes to mind is to build in this behavior into every class that I want to use with my hypothetical custom shared_ptr, and that's not feasible (or possible in some cases).

Edit:

The reason I want this is because I want to use some classes as userdata objects in lua, and I want each one of my objects that I use this way to have a fenv table unique to it that will be cleaned up when all references to the object have been removed. I plan on using the address of the pointer as they key into a table that holds the fenv table.

Lets say I have a widget that can have other widgets as children. I create two widgets in Lua, then set one as the child of the other and remove all lua references to the child widget (the fact that it's a child is handled in C++). The GC can now run at any time and remove the child. I don't necessarily want the child to have it's destructor run though, so I want to make it a shared_ptr. That way, C++ objects can still use it after Lua has cleaned it up. If I've assigned values or functions to it's fenv I still want to be able to access them. Only when the final reference to my child widget is removed do I want the fenv tabled to be removed totally.

Answer 1

if you derive the class your_shared_ptr from shared_ptr and override the destructor, your destructor should be called in code like this:

{
  your_shared_ptr<int> x(new int);
}

If you use it like this, instead:

{
  shared_ptr<int>* ptrptr = new your_shared_ptr<int>(new int);
}

then it won't, but do you really need that?

Or am I misunderstanding something?

Answer 2

You can provide a custom deletion object to be used with the shared_ptr. If you're trying to stick extra information into the shared_ptr, you may be better putting it into the deletion object. It doesn't feel very clean to me, but it works.

class ExtraThingToDestroy
{
  public:
   ~ExtraThingToDestroy() { std::cout<<"Destroying the extra thing"<<std::endl; }
};

template<typename T>
class CustomDestructor
{
  public:
    CustomDestructor( ExtraThingToDestroy * v ) : v_(v) {}
    void operator()( T* t ) { delete t; delete v_; }
    ExtraThingToDestroy * v_;
};

main()
{
   shared_ptr<int> ptr( new int, MyExtraDestructor<int>( new ExtraThingToDestroy ) );
   shared_ptr<int> ptr2 = ptr;
   //Now when ptr and all its copies get destroyed, 
   // the ExtraThingToDestroy will get deleted along with the int.
} 

Answer 3

It already has this ability built in without the need to let people do dangerous things like derive from it:

#include <boost/shared_ptr.hpp>
#include <iostream>

/*
 * Done as a function for simplicity.
 * But this can be done in so many ways
 */
void MyCleanup(int* x)
{
    std::cout << "DONE\n";
    delete x;
}

int main()
{
    boost::shared_ptr<int>  x(new int(5), MyCleanup);

}

Problem with deriving:
Just off the top of my head.

class X: public shared_ptr<int> { /* STUFF. With a special destructor. */ };

int main()
{
    /* what happens now? Similar to slicing but not quite */
    X                data1(new int(5));
    shared_ptr<int>  data2;
    shared_ptr<int>  data3(data);

    data2 = data1;
}

Answer 4

Just make a wrapper object; much easier. You can have the wrapper object have a shared_ptr instance inside it, and still use the allocation address of the internal object as an index. This seems much better than mucking around with derivation or custom cleanup routines, unless I'm missing something.

Eg:

class CWrapsLuaObject
{
    CWrapsLuaObject( LuaObject* pObject )
    { [assign internal ptr, do mapping, etc.] }

    shared_ptr< LuaObject > m_spObject;

    [...]
};

shared_ptr< CWrapsLuaObject > spInstance( new CWrapsLuaObject( pObject ) );

Am I missing why this would not be the easiest solution (not taking anything away from the other suggested solutions, which could also work)?