Связывание Python виртуальная функция-член C ++ не может быть вызвана - PullRequest
Новая
       24

Связывание Python виртуальная функция-член C ++ не может быть вызвана

0 голосов
/ 07 ноября 2018

Я недавно написал расширение для Python 3 на C ++, но столкнулся с некоторыми проблемами, когда вызвал C ++ на python, и я не планирую использовать стороннюю библиотеку.

Я использовал Python-привязку. Виртуальная функция-член C ++ не может быть вызвана, но удаление виртуального ключевого слова в порядке.

Сбой произошел, когда он достиг return PyObject_CallObject(pFunction, args);, но я не нашел причину.

Вот мой код: 

class A 
{
    PyObject_HEAD
public:
    A()
    {
        std::cout << "A::A()" << std::endl;
    }

    ~A()
    {
        std::cout << "A::~A()" << std::endl;
    }

    virtual void test()
    {
        std::cout << "A::test()" << std::endl;
    }
};

class B : public A
{
public:
    B()
    {
        std::cout << "B::B()" << std::endl;
    }

    ~B()
    {
        std::cout << "B::~B()" << std::endl;
    }

    static PyObject *py(B *self) {
        self->test();
        return PyLong_FromLong((long)123456);
    }
};

static void B_dealloc(B *self) 
{
    self->~B();
    Py_TYPE(self)->tp_free((PyObject *)self);
}

static PyObject *B_new(PyTypeObject *type, PyObject *args, PyObject *kwds)
{
    B *self = (B*)type->tp_alloc(type, 0);
    new (self)B;
    return (PyObject*)self;
}

static PyMethodDef B_methods[] = {
    {"test", (PyCFunction)(B::py), METH_NOARGS, nullptr},
    {nullptr}
};

static struct PyModuleDef example_definition = {
    PyModuleDef_HEAD_INIT,
    "example",
    "example",
    -1,
    B_methods
};

static PyTypeObject ClassyType = {
    PyVarObject_HEAD_INIT(NULL, 0) "example.B", /* tp_name */
    sizeof(B),                                  /* tp_basicsize */
    0,                                          /* tp_itemsize */
    (destructor)B_dealloc,                      /* tp_dealloc */
    0,                                          /* tp_print */
    0,                                          /* tp_getattr */
    0,                                          /* tp_setattr */
    0,                                          /* tp_reserved */
    0,                                          /* tp_repr */
    0,                                          /* tp_as_number */
    0,                                          /* tp_as_sequence */
    0,                                          /* tp_as_mapping */
    0,                                          /* tp_hash  */
    0,                                          /* tp_call */
    0,                                          /* tp_str */
    0,                                          /* tp_getattro */
    0,                                          /* tp_setattro */
    0,                                          /* tp_as_buffer */
    Py_TPFLAGS_DEFAULT | Py_TPFLAGS_BASETYPE,   /* tp_flags */
    "B objects",                                /* tp_doc */
    0,                                          /* tp_traverse */
    0,                                          /* tp_clear */
    0,                                          /* tp_richcompare */
    0,                                          /* tp_weaklistoffset */
    0,                                          /* tp_iter */
    0,                                          /* tp_iternext */
    B_methods,                                  /* tp_methods */
    nullptr,                                    /* tp_members */
    0,                                          /* tp_getset */
    0,                                          /* tp_base */
    0,                                          /* tp_dict */
    0,                                          /* tp_descr_get */
    0,                                          /* tp_descr_set */
    0,                                          /* tp_dictoffset */
    nullptr,                                    /* tp_init */
    0,                                          /* tp_alloc */
    B_new,                                      /* tp_new */
};

PyMODINIT_FUNC PyInit_example(void)
{

    PyObject *m = PyModule_Create(&example_definition);

    if (PyType_Ready(&ClassyType) < 0)
        return NULL;

    Py_INCREF(&ClassyType);
    PyModule_AddObject(m, "B", (PyObject*)&ClassyType);

    return m;
}

PyObject* importModule(std::string name)
{
    PyObject* pModule = PyImport_ImportModule(name.c_str());    // module name
    if (pModule == nullptr)
    {
        std::cout << "load module error!" << std::endl;
        return nullptr;
    }

    return pModule;
}

PyObject* callFunction(PyObject* pModule, std::string name, PyObject* args = nullptr)
{
    PyObject* pFunction = PyObject_GetAttrString(pModule, name.c_str());    // function name
    if (pFunction == nullptr)
    {
        std::cout << "call function error!" << std::endl;
        return nullptr;
    }

    return PyObject_CallObject(pFunction, args);
}

int main()
{
    // add module
    PyImport_AppendInittab("example", PyInit_example);

    // init python
    Py_Initialize();
    {
        PyRun_SimpleString("import sys");
        PyRun_SimpleString("import os");
        PyRun_SimpleString("sys.path.append(os.getcwd() + '\\script')");    // add script path
    }

    // import module
    PyImport_ImportModule("example");

    PyObject* pModule = importModule("Test");
    if (pModule != nullptr)
    {
        PyObject* pReturn = callFunction(pModule, "main");
    }

    PyErr_Print();

    Py_Finalize();

    system("pause");
    return 0;
}

1 Ответ

0 голосов
/ 07 ноября 2018

Я предполагаю, что OP использует API CPython . ( Мы используем CPython, и части кода выглядят очень похожими / знакомыми.)

Как уже сказано в названии, оно написано на C.

Таким образом, при использовании его для написания привязки Python для классов C ++ разработчик должен знать, что CPython и его API C не & ldquo; знают & rdquo; что-нибудь о C ++. Это должно быть тщательно продумано (похоже на написание связывания C для библиотеки классов C ++).

Когда я пишу классы Python Wrapper, я делаю это всегда с struct s (чтобы помнить об этом). Можно использовать наследование C ++ в оболочках CPython, чтобы напоминать наследование обернутых классов C ++ (но это единственное исключение из моего вышеприведенного правила).

struct и class - это одно и то же в C ++, за исключением (единственного), что по умолчанию все равно public в struct, а class - private. SO: Класс против Struct только для данных? Кстати. CPython получит доступ к его соотв. переменные-члены компоненты структуры (например, ob_base) от приведения указателя C (переинтерпретация приведения) и даже не будут распознавать private -security-попытки.

ИМХО, стоит упомянуть термин POD ( обычные старые данные , также называемый пассивная структура данных ), потому что это то, что делает классы-оболочки C ++ совместим с C. SO: Что такое агрегаты и POD и как / почему они особенные? дает полный обзор этого.

Введение хотя бы одной virtual функции-члена в класс-оболочку CPython имеет фатальные последствия. Внимательно прочитав приведенную выше ссылку, вы поймете это. Однако я решил проиллюстрировать это небольшим примером кода: 

#include <iomanip>
#include <iostream>

// a little experimentation framework:

struct _typeobject { }; // replacement (to keep it simple)
typedef size_t Py_ssize_t; // replacement (to keep it simple)

// copied from object.h of CPython:
/* Define pointers to support a doubly-linked list of all live heap objects. */
#define _PyObject_HEAD_EXTRA            \
    struct _object *_ob_next;           \
    struct _object *_ob_prev;

// copied from object.h of CPython:
/* Nothing is actually declared to be a PyObject, but every pointer to
 * a Python object can be cast to a PyObject*.  This is inheritance built
 * by hand.  Similarly every pointer to a variable-size Python object can,
 * in addition, be cast to PyVarObject*.
 */
typedef struct _object {
  _PyObject_HEAD_EXTRA
  Py_ssize_t ob_refcnt;
  struct _typeobject *ob_type;
} PyObject;

/* PyObject_HEAD defines the initial segment of every PyObject. */
#define PyObject_HEAD                   PyObject ob_base;

void dump(std::ostream &out, const char *p, size_t size)
{
  const size_t n = 16;
  for (size_t i = 0; i < size; ++p) {
    if (i % n == 0) {
      out << std::hex << std::setw(2 * sizeof p) << std::setfill('0')
        << (size_t)p << ": ";
    }
    out << ' '
      << std::hex << std::setw(2) << std::setfill('0')
      << (unsigned)*(unsigned char*)p;
    if (++i % n == 0) out << '\n';
  }
  if (size % n != 0) out << '\n';
}

// the experiment:

static PyObject pyObj;

// This is correct:
struct Wrapper1 {
  PyObject_HEAD
  int myExt;
};
static Wrapper1 wrap1;

// This is possible:
struct Wrapper1Derived: Wrapper1 {
  double myExtD;
};
static Wrapper1Derived wrap1D;

// This is effectively not different from struct Wrapper1
// but things are private in Wrapper2
// ...and Python will just ignore this (using C pointer casts).
class Wrapper2 {
  PyObject_HEAD
  int myExt;
};
static Wrapper2 wrap2;

// This is FATAL - introduces a virtual method table.
class Wrapper3 {
  private:
    PyObject_HEAD
    int myExt;
  public:
    Wrapper3(int value): myExt(value) { }
    virtual ~Wrapper3() { myExt = 0; }
};
static Wrapper3 wrap3{123};

int main()
{
  std::cout << "Dump of PyObject pyObj:\n";
  dump(std::cout, (const char*)&pyObj, sizeof pyObj);
  std::cout << "Dump of Wrapper1 wrap1:\n";
  dump(std::cout, (const char*)&wrap1, sizeof wrap1);
  std::cout << "Dump of Wrapper1Derived wrap1D:\n";
  dump(std::cout, (const char*)&wrap1D, sizeof wrap1D);
  std::cout << "Dump of Wrapper2 wrap2:\n";
  dump(std::cout, (const char*)&wrap2, sizeof wrap2);
  std::cout << "Dump of Wrapper3 wrap3:\n";
  dump(std::cout, (const char*)&wrap3, sizeof wrap3);
  return 0;
}

Скомпилировано и запущено: 

Dump of PyObject pyObj:
0000000000601640:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000000000601650:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Dump of Wrapper1 wrap1:
0000000000601600:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000000000601610:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000000000601620:  00 00 00 00 00 00 00 00
Dump of Wrapper1Derived wrap1D:
00000000006015c0:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000000006015d0:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000000006015e0:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Dump of Wrapper2 wrap2:
0000000000601580:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000000000601590:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000000006015a0:  00 00 00 00 00 00 00 00
Dump of Wrapper3 wrap3:
0000000000601540:  d8 0e 40 00 00 00 00 00 00 00 00 00 00 00 00 00
0000000000601550:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000000000601560:  00 00 00 00 00 00 00 00 7b 00 00 00 00 00 00 00

Демонстрация в реальном времени на coliru

Дампы pyObj, wrap1, wrap1D, wrap2 состоят только из 00 s & ndash; неудивительно, я сделал их static. wrap3 выглядит немного по-другому, частично из-за конструктора (7b == 123) и частично из-за того, что компилятор C ++ поместил понтер VMT в экземпляр класса, к которому очень вероятно принадлежит d8 0e 40. (Я предполагаю, что указатель VMT имеет размер любого указателя на функцию, но на самом деле я не знаю, как компилятор организует вещи внутренне.)

Представьте себе, что происходит, когда CPython берет адрес wrap3, преобразует его в PyObject* и записывает указатель _ob_next со смещением 0, который используется для объединения объектов Python в двойной список. (Надеюсь, что это сбой или что-то еще, что еще больше ухудшит ситуацию.)

Представьте, в свою очередь, что происходит в функции создания OP 

static PyObject *B_new(PyTypeObject *type, PyObject *args, PyObject *kwds)
{
    B *self = (B*)type->tp_alloc(type, 0);
    new (self)B;
    return (PyObject*)self;
}

, когда конструктор размещения B переопределяет инициализацию внутренних элементов PyObject, что, вероятно, произошло в tp_alloc().

...