C ++ Вызов финальной виртуальной функции в конструкторе

Question

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

Однако что произойдет, если в конструкторе или деструкторе вызывается виртуальная final функция?Я предполагаю, что не должно быть никаких проблем, поскольку это не логически неправильно.

Вызов виртуальной функции в конструкторе и деструкторе запрещен, поскольку доступ к переменной подкласса, еще не инициализированной, может происходить в переопределенной версии виртуальной функции, которая объявлена ​​в подклассе.

Хотя виртуальной финальной функции нет, она финальная, и нет никакого доступа к переменным подкласса.

Но это мое предположение, и могут быть и другие причины, по которым вызов виртуальной функции в конструкторе или деструкторе нецелесообразен.

Итак, в заключение,

• Разрешен ли вызов виртуальной final функции в фазе конструирования / разрушения в стандарте C ++?
• Если да, широко ли он применяется в большинстве компиляторов C ++?
• Если это не так, есть ли причина для этого?

Answer 1

Разрешен ли вызов виртуальной конечной функции в фазе конструирования / разрушения в стандарте C ++?

Вызов виртуальной функции во время конструирования / уничтожения четко определен и полностьюдопустимо за исключением случая чисто виртуальных функций .

Запрещен вызов виртуальной функции в конструкторе и деструкторе

Не знаю (низаботится) кто говорит, что это «плохо» или «запрещено» с стилистической точки зрения, с точки зрения обслуживания кода ... Способность поддерживать код зависит, прежде всего, от хорошего знания соответствующего языка и инструментов;незнание того, что делают виртуальные вызовы на этих этапах (*), приведет к неправильному пониманию со стороны сопровождающих, что устраняется путем выбора более опытных сопровождающих и не сбивает с толку стиль программирования.

(*), которые не 'Технически это часть «времени жизни» объекта, которое даже не очень полезно, поскольку объекты могут использоваться и использоваться в их конструкторе (до начала их жизни) в любой нетривиальной программе (я думаю, что стандарт должен просто подавлятьэта ненужная концепция).

доступ к переменной подкласса, еще не инициализированной, может происходить в переопределенной версии виртуальной функции, которая объявлена ​​в подклассе.

Itне может.При создании подобъекта базового класса B (скажем, с помощью конструктора B::B()), тип создаваемого объекта по определению B.

переопределяетсяверсия виртуальной функции, которая объявлена ​​в подклассе.

Нет, нет существующего объекта подкласса в этой точке , поэтому переопределения нет.

Хотя виртуальной конечной функции нет, она является конечной и нет возможности получить доступ к переменным подкласса.

Это не имеет значения.

Динамический тип полиморфного типаобъект устанавливается конструктором после конструкторов для базовых классов и до конструирования членов.

Если да, широко ли он применяется в большинстве компиляторов C ++?

На практикевсе компиляторы реализуют установку динамического типа объекта путем изменения одного или нескольких указателей vtable, чтобы они указывали на соответствующие vtables для типа;это делается как часть построения.

Это означает, что во время построения значение vptr изменяется при построении производных объектов.