Доступ к статическим членам класса из dll

У меня есть приложение, написанное на C++, которое использует SWIG для интеграции с Python.

Теперь под linux/osx, когда я создаю оболочку swig, он создает такой файл, который используется из такого приложения.

Py_Initialize();
PyRun_SimpleString("import MoBridge");
PyRun_SimpleString("a = MoBridge.MoBridge()");
PyRun_SimpleString("a.CreateQuadMesh()");
Py_Finalize();

Это делает то, что он импортирует оболочку MoBridge, а затем вызывает через оболочку C++ функцию CreateQuadMesh(). Обертка примерно выглядит примерно так

ч файл:

#include "MoEngine.h"

class MoBridge
{
public:
    MoBridge();
    ~MoBridge();
    void CreateQuadMesh();
};

СРР-файл:

#include "mobridge.h"

void MoBridge::CreateQuadMesh()
{
    MoEngine::CreateMesh();
}

Оболочка вызывает статическую функцию MoEngine, а она, в свою очередь, делает то, что делает.

Теперь это прекрасно работает под Linux/osx, если я правильно понял, потому что файл связан таким образом.

Но под окнами мне пришлось создать DLL, и, насколько я обнаружил, файлы DLL загружаются по-разному, поэтому они живут в памяти, отличной от остальной части приложения, и, следовательно, не могут видеть приложения с другими статическими методами.

Я знаю, что могу использовать dllexport для предоставления методов из dll остальной части приложения. Но в этом случае я ищу, как разрешить dll доступ к остальным статическим функциям приложений в памяти приложений.

Я был бы признателен за любую точку в правильном направлении.


person listener    schedule 26.03.2015    source источник
comment
stackoverflow.com/questions/8654327 / stackoverflow.com/questions/4911994/ Я думаю, что они рассматривают ваш вопрос. Дайте ему прочитать   -  person Mercious    schedule 26.03.2015


Ответы (1)


Если кто-то застрял с этим, я нашел решение, которое решит эту проблему как в Linux, OSX, так и в Windows.

использование общего объекта *.so, конечно, будет работать с linux/osx, но, к счастью, есть еще более простое решение для использования с SWIG, которое на самом деле не задокументировано в SWIG, но задокументировано в документации по python (спасибо, python!)

Чтобы это работало, вам не нужно создавать файл dll или около того из вашей оболочки, но после того, как swig создаст ваш файл *_wrap.cxx, вы должны включить его в свой проект, и перед вызовом Py_Initialize() вы импортируете свой модуль следующим образом.

PyImport_AppendInittab("_MoBridge", PyInit__MoBridge);

Затем вы можете использовать, как упоминалось ранее:

Py_Initialize();
PyRun_SimpleString("import MoBridge");
PyRun_SimpleString("a = MoBridge.MoBridge()");
PyRun_SimpleString("a.CreateQuadMesh()");
Py_Finalize();

И в основном, поскольку у вас есть *_wrap.cxx в вашем проекте, а python, по сути, живет в вашем приложении, поскольку вы его инициализировали, у вас точно такое же поведение, как если бы вы использовали его в linux/osx, за исключением этой работы на всех трех платформах.

Ваше здоровье!

person listener    schedule 26.03.2015