IAR EWAVR и виртуальные функции Опции

[AlexG_changed]

Компилятор IAR EWAVR 4.20A
Микроконтроллер ATmega128

В программе есть родительский класс и два наследованных от него класса, отличающихся парой функций.
При объявлении соответствующих функций родительского класса виртуальными программа виснет где-то между __low_level_init() и main(). Если сделать функции не виртуальными, то программа работает, но вызываются функции родительского класса, а не наследованных, что делает использование наследования в данном случае бессмысленным.

В чем может быть причина полной неработоспособности программы с виртуальными функциями?

После очередной перекомпиляции еще интереснее:
The application aborted
Program exit reached

(отлаживаю под JTAG ICE)

Сообщение отредактировал AlexG - Nov 12 2007, 12:47

[Непомнящий Евген...]

Я понимаю, что такой стандарт, но все ж таки как-то неудобно. Фактически получается, что любой вызов виртуальной функции в конструкторе приводит в ошибке времени выполнения. Хотя б какой-нибудь ворнинг выдавался...

Где тут лежит объект и что об этом знает компилятор?

Когда вы пишите TSlon *p = new TSlon, то вначале вызывается operator new(), затем контсруктор TSlon и только затем инициализируется __vptr. Не до конца понятно, почему нельзя инициализировать __vptr до вызова конструктора - указатель на память, где будет расположен объект, уже есть.

[IgorKossak]

...
Когда вы пишите TSlon *p = new TSlon, то вначале вызывается operator new(), затем контсруктор TSlon и только затем инициализируется __vptr. Не до конца понятно, почему нельзя инициализировать __vptr до вызова конструктора - указатель на память, где будет расположен объект, уже есть.

Ну и на что должен указывать этот указатель? На обьект, который там скоро появится?
Напоминает фразу: "Вы жарьте, а рыба будет".

[Непомнящий Евген...]

Ну и на что должен указывать этот указатель? На обьект, который там скоро появится?
Напоминает фразу: "Вы жарьте, а рыба будет".

Указатель должен указывать на массив указателей на реализации виртуальных функции.

После вызова operator new уже есть указатель на (неиниализированную) память. В этой точке также известна структура создаваемого объекта и его тип - т.е. известно, чему равен __vptr и где он находится. Почему нельзя его записать до вызова пользовательского конструктора, а не после?

[dxp]

После вызова operator new уже есть указатель на (неиниализированную) память. В этой точке также известна структура создаваемого объекта и его тип

Кому известно? Пральна - конструктору.

- т.е. известно, чему равен __vptr и где он находится. Почему нельзя его записать до вызова пользовательского конструктора, а не после?

Потому, что по-вашему получается, что надо иметь два конструктора - один предварительный, для создания/инициализации vptr, второй - для всего остального.

Какая такая необходимость вызвать виртуальные функции на стадии конструирования объекта?

[Непомнящий Евген...]

Какая такая необходимость вызвать виртуальные функции на стадии конструирования объекта?

Ну напоролся же один раз - значит была необходимость. Когда понял в чем дело - обошелся
Счас еще раз пересмотрел Страуструпа - не нашел указаний на то, что в конструкторе нельзя дергать виртуальные функции...

[dxp]

Счас еще раз пересмотрел Страуструпа - не нашел указаний на то, что в конструкторе нельзя дергать виртуальные функции...

Наверняка вы у него не найдете и того, что не надо вызывать функцию main из других функций, но это не означает, что такоей вызов надо делать?

Вопрос был о том, зачем вызывать виртуальную функцию из конструируемого объекта, в котором однозначно this содержит адрес текущего (этого конструируемого) объекта и будет вызваться совершенно понятно какая функция - т.е. никакой виртуальности тут нет, один только оверхед. Даже если проинициализировать vptr так, как вы хотите, виртуального по сути вызова тут не получится.