У меня есть следующий класс C ++:
.ЧАС
class ALabSet: public LabSet {
public:
PyObject *m_obj;
ALabSet(PyObject *obj);
virtual ~ALabSet();
PyObject *GetPyObj();
};
.CPP
ALabSet::ALabSet(PyObject *obj): LabSet() {
this->m_obj = obj;
// Provided by "cyelp_api.h"if (import_cyelp()) {
} else {
Py_XINCREF(this->m_obj);
}
}ALabSet::~ALabSet() {
Py_XDECREF(this->m_obj);
}PyObject *ALabSet::GetPyObj() {
return this->m_obj;
}
Я показал это следующим образом с Cython:
cdef extern from "adapter/ALabSiteSetsManager.h" namespace "elps" :
cdef cppclass ALabSet:
ALabSet(PyObject *)
PyObject *GetPyObj()cdef class PyLabSet:
cdef ALabSet *thisptr
def __cinit__(self):
self.thisptr = new ALabSet(<PyObject *>self)
def __dealloc__(self):
print "delete from PY !"if self.thisptr:
del self.thisptr
Моя проблема в том, что я не могу понять, как вызвать деструктор из Python. Следующее ничего не делает:
a_set = PyLabSet()
del a_set
Я не могу найти похожие проблемы в Интернете. У кого-нибудь из вас есть идея о том, чтобы приехать ко мне сюда?
Я что-то упускаю из-за управления подсчетом ссылок, или …
большое спасибо
del a_set
удаляет ссылку на объект (локальная переменная) Есть еще одна ссылка в объекте C ++. Это известно как контрольный цикл. Цикл ГК мог собери это через некоторое время. Тем не менее, нет никакой гарантии, когда (или даже если) это происходит, поэтому не стоит на это полагаться1.
Например, ссылочные циклы, содержащие чистые объекты Python с __del__
особый метод документированы не быть освобожденным совсем:
Изменено в версии 3.4: после PEP 442 объекты с
__del__()
метод не заканчиваетсяgc.garbage
больше.
Не знаю Реализация Cython __dealloc__
вызывает такое поведение, но, как было указано выше, разрушение в любом случае не является детерминированным. Если вы хотите освободить некоторый ресурс (например, блок памяти, который не является объектом Python, файл, соединение, блокировку и т. Д.), Вы должны предоставить явный способ сделать это вручную (см. close
методы различных объектов). Менеджеры контекста могут упростить клиентский код, делая это.
Отказ от ответственности: Почти все это зависит от CPython.
1 Некоторые люди предпочитают думать о GC как об абстракции, которая имитирует наличие бесконечной памяти, а не как нечто, разрушающее недоступные объекты. При таком подходе становится совершенно очевидно, что разрушение не является детерминированным и даже не гарантируется.
Других решений пока нет …