У меня есть простой класс C ++ под названием Square, который наследуется от Comparable (интерфейс с функцией compareTo).
Вот реализация C ++ метода CompareTo:
int Square::compareTo(Comparable* c, char criteria) {
if (dynamic_cast<Square*>(c) != NULL) {
return 2;
}
else {
return 4;
}
}
Я сгенерировал libray (.so файл) с помощью Android-ndk (r8c). Найдите ниже код Android.mk и Application.mk
Android.mk:
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := testinterface
LOCAL_SRC_FILES := wrappers.cpp Shape.cpp Square.cpp Circle.cpp
LOCAL_CPP_FEATURES += rtti
//LOCAL_CFLAGS := -frtti -> The commented lines were tests
//LOCAL_CPP_FEATURES += exceptions
//LOCAL_CPPFLAGS += -fexceptions
include $(BUILD_SHARED_LIBRARY)
Application.mk:
//APP_CPPFLAGS += -frtti -> That was for a test but it didn't work either
APP_STL := gnustl_static
И вот код Java, который я использую для вызова функции compareTo (я использовал SWIG для генерации оболочек Java):
Square s = new Square(10);
Square s3 = new Square(10);
outputText.append("s.compareTo(s3) ? " + s.compareTo(new Comparable(Square.getCPtr(s3), false), 'c') +"\n");
Результат показывает 4 в отношении кода c ++, который означает, что s3 не является квадратом. Проблема в том, что если я изменю APP_STL := gnustl_static
в APP_STL := stlport_static
в файле Application.mk результат равен 2.
Кто-нибудь может мне помочь ?
Являются ли конструктор и dynmic_cast
в разных общих
объекты? И если да, то какие варианты были переданы dlopen
?
Если общие объекты загружены RTLD_LOCAL
тогда г ++
рассмотрим тип Square
в одном, не связанном с
тип Square
в другом, так что dynamic_cast
не удастся.
Если ты не звонишь dlopen
явно, то неявное
load будет использовать флаги, используемые для загрузки общего объекта, который
нужны ваши общие объекты. Когда Java загружает общий объект, он
использования RTLD_LOCAL
, что означает любые другие общие объекты
неявно загруженный этим общим объектом также будет использовать
RTLD_LOCAL
, В нашем случае мы создали небольшой общий интерфейс
объект, который не сделал ничего, кроме загрузки всех общих
объекты нам нужны, в порядке, определяемом зависимостями,
чтобы не было никакой нагрузки, и мы могли бы контролировать
абсолютно аргументы dlopen
, Мы сделали это, выведя
все классы Java, которые вызвали в нашу библиотеку
общий базовый класс, который содержит что-то вроде:
// In the Java base class...
private static native void initializeLibrary();
static
{
System.loadLibrary("WrapperLibrary");
initializeLibrary();
}
initializeLibrary()
Функция затем сделала последовательность
явный dlopen
в зависимости определяется порядок.
Других решений пока нет …