Почему у shared_ptr нет виртуального дескриптора? (и как я могу обойти это?)

Question

Я хотел сделать специальную версию shared_ptr, которая выполняла бы определенные операции, когда она была создана или уничтожена, но мои планы, похоже, были сорваны реализацией того, что деструктор shared_ptr не является виртуальный, то есть когда я переопределяю его, мои указатели никогда не очищаются, когда последний экземпляр их уничтожается.

Единственной альтернативой, которая приходит на ум, является построение этого поведения в каждом классе, который я хочу использовать с моим гипотетическим пользовательским shared_ptr, и это невозможно (или возможно в некоторых случаях).

Edit:

Причины, я хочу это, потому что я хочу использовать некоторые классы как USERDATA объектов в Lua, и я хочу, чтобы каждый из моих объектов, которые я использую этот способ иметь таблицу fenv уникальную для него который будет очищен, когда все ссылки на объект будут удалены. Я планирую использовать адрес указателя, когда они входят в таблицу, содержащую таблицу fenv.

Допустим, у меня есть виджет, который может иметь другие виджеты в качестве детей. Я создаю два виджета в Lua, затем устанавливаю его как дочерний элемент другого и удаляю все ссылки lua на дочерний виджет (тот факт, что он является дочерним, обрабатывается на C++). Теперь GC может работать в любое время и удалять ребенка. Я не обязательно хочу, чтобы у ребенка был его деструктор, хотя я хочу сделать его shared_ptr. Таким образом, объекты C++ все еще могут использовать его после того, как Lua очистит его. Если я присвоил значения или функции этому файлу, я все равно хочу иметь к ним доступ. Только когда окончательная ссылка на мой дочерний виджет будет удалена, я хочу, чтобы fenv был удален полностью.

Answer 1

Он уже имеет эту возможность, построенный в, без необходимости, чтобы позволить людям делать опасные вещи, как извлечь из него:

#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); 

} 

Проблема с извлечением:
Только от верхней части моей головы.

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 2

если вы черпаете класс your_shared_ptr от shared_ptr и переопределить деструктор, ваш деструктор должен быть вызван в коде следующим образом:

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

Если вы используете его, как это, вместо того, чтобы:

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

то это не будет, но вам это действительно нужно?

Или я что-то не понимаю?

Answer 3

Вы можете указать пользовательский объект удаления, который будет использоваться совместно с shared_ptr. Если вы пытаетесь вставить дополнительную информацию в shared_ptr, вы можете лучше помещать ее в объект удаления. Для меня это не очень чисто, но это работает.

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 4

Просто сделайте объект-обертку; намного легче. Вы можете иметь объект-оболочку с экземпляром shared_ptr внутри него и по-прежнему использовать адрес распределения внутреннего объекта в качестве индекса. Это кажется намного лучше, чем сбрасывание с помощью деривации или пользовательских процедур очистки, если только я что-то не пропускаю.

Например:

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 отсутствует, почему это не было бы самым простым решением (не принимая ничего от других предложенных решений, которые могли бы также работать)?