Как создать два прокси-класса, используя один и тот же интерфейс в Swig

У меня есть код, как показано ниже:

class SingleValue
{
public:
SingleValue()
{}

~SingleValue()
{}

const std::string& getValue()const
{
return m_nSingleValue;
}
private:
int m_nSingleValue;
};

typedef SingleValue RoadType;
typedef SingleValue RoadSubType;
typedef SingleValue FunctionalClass;

теперь я хочу использовать SWIG для генерации Java-оболочки, но он генерирует только один прокси-класс ‘SingleValue’, я хочу знать, как генерировать другой прокси-класс, используя swig, но я не могу найти некоторую относительную информацию после поиска в Google.

Я пытаюсь% переименовать, но он генерирует только один прокси-класс, а не три.

1

Решение

То, чего ты пытаешься достичь, похоже на строгую типизацию. SWIG по умолчанию пытается представить интерфейс с тем же поведением, которое вы видели бы в C ++, поэтому в этом случае ожидается ожидаемое поведение — слабые определения типов — это все предложения C ++. Вы можете обойти это все же.

Учитывая заголовок файла:

#include <string>

class SingleValue
{
public:
SingleValue()
{}

~SingleValue()
{}

std::string getValue() const
{
return std::to_string(m_nSingleValue);
}
private:
int m_nSingleValue;
};

typedef SingleValue RoadType;
typedef SingleValue RoadSubType;
typedef SingleValue FunctionalClass;

inline RoadType make_road() { return RoadType(); }
FunctionalClass make_func() { return FunctionalClass(); }

который отличается от вашего только исправлениями к getValue() и добавление двух встроенных функций для тестирования, мы можем обернуть его и приблизиться к строгой семантике typedef, выполнив:

%module test

%{
#include "test.h"%}

%include <std_string.i>

class SingleValue
{
public:
SingleValue();
~SingleValue();
std::string getValue() const;
};

struct RoadType : public SingleValue {
};

struct RoadSubType : public SingleValue {
};

struct FunctionalClass : public SingleValue {
};

RoadType make_road();
FunctionalClass make_func();

Обратите внимание, что я вообще не показывал SWI-код typedef и полностью соврал насчет типа и существования RoadType и т. д., но это нормально, потому что весь код, сгенерированный SWIG, все еще корректен и корректен.

Это вызывает создание интерфейса, где make_X функции возвращают различные типы.


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

#include <string>

class SingleValue
{
public:
SingleValue()
{}

~SingleValue()
{}

std::string getValue() const
{
return std::to_string(m_nSingleValue);
}
private:
int m_nSingleValue;
};

#ifndef STRONG_TYPEDEF
#define STRONG_TYPEDEF(o,n) typedef o n
#endif

STRONG_TYPEDEF(SingleValue, RoadType);
STRONG_TYPEDEF(SingleValue, RoadSubType);
STRONG_TYPEDEF(SingleValue, FunctionalClass);

inline RoadType make_road() { return RoadType(); }
FunctionalClass make_func() { return FunctionalClass(); }

Это означает, что файл интерфейса может просто стать:

%module test

%{
#include "test.h"%}

%include <std_string.i>

#define STRONG_TYPEDEF(o, n) struct n : o {};

%include "test.h"

Это работает отчасти потому, что SingleValue это класс, поэтому сильный typedef может стать подклассом в системе типов Java, чтобы он включал проверку. Если тип не является классом, вы все равно можете сделать то же самое без использования наследования, например первая часть ответа я дал на похожую проблему сработало бы использование D — вам бы хотелось уточнить пустые структуры, хотя, если в игре нет наследства.

1

Другие решения

Других решений пока нет …

По вопросам рекламы [email protected]