Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Keil и виртуальные методы (С++)
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > Cредства разработки для МК > GNU/OpenSource средства разработки
poganoe_lamerishe
Я понимаю, что Кейл - не опенсорс, но вопрос все же по среде разработки, а не по контроллеру, поэтому разместил топик в этой ветке. Если был не прав, поправьте пожалуйста.

Так вот. Насколько я знаю, стандарт С++ не оговаривает реализацию виртуальных методов, т.е. даже само существование vtab отдается на откуп компилятору.
Компилируя простой код в Кейле (для Cortex M3) я заметил интересную вещь.
Код
class Base
{
    public:
    virtual ~Base() {}
};

class Derived : public Base
{

    public:
    int b;

    virtual ~Derived() {}
};


Если создать экземпляр класса Derived на стеке (локально), то все в порядке, все компилируется и отлаживается. При этом размер компилированного кода составляет 356 байт.

Если создать экземпляр глобально или статически, то код резко распухает до 1144 байт и отладка повисает на листинге:
0x0000045C BEAB BKPT 0xAB
0x0000045E E7FE B 0x0000045E

Опытным путем я обнаружил, что если в стартапном файле задать ненулевой размер кучи (а нулевой он по дефолту), то отладка идет нормально.
Поглядев на экземпляры класса в watch, я увидел, что указатели __vtab указывают в разные места у локального и глобального (или статического) экземпляров. Локальный ссылался в оперативку, глобальный - во флеш. Ошибся, пардон.

Вопрос, собственно, вот в чем - а нафига тут куча-то? И как ее безболезненно убрать? А то лишний килобайт без всякой причины как-то не радует.

UPD: Попробовал размещать глобальный экземпляр по фиксированному адресу с помощью __attribute__((at(0x10000800))) - ничего не изменилось, куча все равно нужна. Но зачем?
poganoe_lamerishe
Что интересно, если сделать виртуальным обычный метод, а не деструктор, то такого поведения не наблюдается.
Если деструктор сделать невиртуальным, но запихать его в protected, то наблюдается. Очень интересно.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.