2016-02-01 13 views
0

Я работаю над приложением QNX/Blackberry 10. Моя заявка недавно начала крах. Вставка инструкций трассировки заставила меня поверить, что авария происходит в следующей ситуации.Ошибка моего приложения QNX/BB10 C++, кажется, что объект C++ поврежден

Приложение-клиент вызывает внутреннюю функцию, передавая ей ссылку на объект класса C++. Принятый класс C++ выглядит следующим образом:

class ALPeerData 
{ 
public: 
    ALPeerData(); 
    virtual ~ALPeerData(); 

    int   _peerId; 
    ALModelType _modelType; 
    std::wstring _computerName; 
    std::wstring _uuidDevice; 
    . . . 
}; 

происходит сбой, когда я получить доступ к _computerName или _uuidDevice переменным членам после того, как вызываемая функция возвращает его. Трассировки в вызываемой функции показывают, что переменные-члены объекта ALPeerData ожидаются. Таким образом, _computerName.size() в функции возвращает что-то разумное, как 10, но при вызове в клиентском приложении возвращает размер около 23 МБ. The ALPeerData объект, кажется, поврежден.

Я перечисляю здесь QCC выход -V по причинам документации:

user:~$ qcc -V 
cc: targets available in /home/bbndk/host_10_3_1_12/linux/x86/etc/qcc: 
     4.6.3,gcc_ntoarmv7le_gpp 
     4.6.3,gcc_ntox86_gpp 
     4.6.3,gcc_ntoarmv7le_cpp-ne 
     4.6.3,gcc_ntoarmv7le_cpp 
     4.6.3,gcc_ntox86  (default) 
     4.6.3,gcc_ntoarmv7le 
     4.6.3,gcc_ntox86_cpp-ne 
     4.6.3,gcc_ntox86_cpp 
     4.8.3,gcc_ntoarmv7le_gpp 
     4.8.3,gcc_ntox86_gpp 
     4.8.3,gcc_ntoarmv7le_cpp-ne 
     4.8.3,gcc_ntoarmv7le_cpp 
     4.8.3,gcc_ntox86 
     4.8.3,gcc_ntoarmv7le 
     4.8.3,gcc_ntox86_cpp-ne 
     4.8.3,gcc_ntox86_cpp 
user:~$ 

Что может быть не так с моим ALPeerData классом?

ответ

0

Оказывается, QNX имеет проблему с его реализацией стандарта C++ в своем компиляторе gcc/qcc.

Ключевое слово 'virtual' в объявлении деструктора ALPeerData не является необходимым и избыточным, поскольку из моего приложения не вытекает из этого класса. Это не должно иметь никакого значения - мне должно быть позволено указать «виртуальный» для любого деструктора, которого я прошу.

В действительности, указание «virtual» для деструктора ALPeerData вызывает создание некорректного двоичного кода. Таким образом, доступ к переменным-членам приводит к результатам мусора.

Когда я удалил избыточное «виртуальное» ключевое слово, авария исчезла.

Это не первый случай, когда я столкнулся с проблемой реализации QNX виртуальных деструкторов C++. Первый раз можно увидеть в previous StackOverflow post of mine.

Суть: нужно быть осторожным относительно реализации виртуальных деструкторов QNX.

+0

Я не понимаю. Почему вы объявляете деструктор виртуальным, если ваш основной класс не является производным от другого. –

+0

Я добавил ключевое слово «virtual», чтобы помочь другому разработчику, который в будущем будет получен из ALPeerData. Сделать это виртуальным, избегая общей ошибки базового деструктора, не получившего вызова. В соответствии с официальной спецификацией на С ++ это абсолютно доброкачественное. См. Http://stackoverflow.com/questions/300986/when-should-you-not-use-virtual-destructors для обсуждения того, как сделать все деструкторы виртуальными. Другой теоретический сценарий: предположим, что производный класс _had_ был получен из ALPeerData, но позже был удален из кода во время рефакторинга, не удаляя ключевое слово virtual из ALPeerData. –

+0

Ahhhhhhhhh ....... Я понял. Muchas gracias, amigo. –

 Смежные вопросы

  • Нет связанных вопросов^_^