dynamic_cast ведет себя не так, как должен с APP_STL: = gnustl_static

У меня есть простой класс 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.

Кто-нибудь может мне помочь ?

0

Решение

Являются ли конструктор и 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в зависимости определяется порядок.

0

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

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

По вопросам рекламы ammmcru@yandex.ru
Adblock
detector