Сергей Малышев (aka Михалыч)

Часть 1. Общая теория виртуальных функций

Посмотрев на название этой статьи, вы можете подумать: "Хм! Кто же не знает, что такое виртуальные функции! Это же..." Если это так, можете смело бросить чтение прямо на этом месте.

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

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

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

Так что же это такое?

Давайте для начала вспомним, как в классическом программировании на С вы можете передать объект данных в функцию. Ничего сложного в этом нет, надо только задать тип передаваемого объекта в то время, когда вы пишете код функции. То есть, чтобы описать поведение объектов, необходимо заранее знать и описать их тип. Сила ООП в этом случае проявляется в том, что вы можете писать виртуальные функции так, чтобы объект сам определял, какую функцию ему необходимо вызвать, во время выполнения программы.

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

Ну вот, а теперь к делу!

Как известно, согласно правилам С++, указатель на базовый класс может ссылаться на объект этого класса, а также на объект любого другого класса, производного от базового. Понимание этого правила очень важно. Давайте рассмотрим простую иерархию неких классов А, В и С. А будет у нас базовым классом, В - выводится (порождается) из класса А, ну а С - выводится из В. Пояснения смотрите на рисунке.

В программе объекты этих классов могут быть объявлены, например, таким образом.

A object_A; //объявление объекта типа А
B object_B; //объявление объекта типа В
C object_C; //объявление объекта типа С

Согласно данному правилу указатель типа А может ссылаться на любой из этих трех объектов. То есть вот это будет верным:

point_to_Object=&object_C; //присвоим указателю адрес объекта С

А вот это уже не правильно:

В *point_to_Object; // объявим указатель на производный класс
point_to_Object=&object_А; //нельзя присвоить указателю адрес базового объекта

Несмотря на то, что указатель point_to_Object имеет тип А*, а не С* (или В*), он может ссылаться на объекты типа С (или В). Может быть правило будет более понятным, если вы будете думать об объекте С, как особом виде объекта А. Ну, например, пингвин - это особая разновидность птиц, но он все таки остается птицей, хоть и не летает. Конечно, эта взаимосвязь объектов и указателей работает только в одном направлении. Объект типа С - особый вид объекта А, но вот объект А не является особым видом объекта С. Возвращаясь к пингвинам смело можно сказать, что если бы все птицы были особым видом пингвинов - они бы просто не умели летать!

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

class A
{
public:
virtual void v_function(void);//функция описывает некое поведение класса А
};

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

Если в классе В, порожденном от класса А нужно описать коке-то другое поведение, то можно объявить виртуальную функцию, названную опять-таки v_function() .

class B: public A
{
public:
virtual void v_function(void);//замещающая функция описывает некое
//новое поведение класса В
};

Когда в классе, подобном В, определяется виртуальная функция, имеющая одинаковое имя с виртуальной функцией класса-предка, такая функция называется замещающей. Виртуальная функция v_function()в В замещает виртуальную функцию с тем же именем в классе А. На самом деле все несколько сложнее и не сводится к простому совпадению имен. Но об этом чуть позже, в разделе "Некоторые тонкости применения".
Ну, а теперь самое важное!

Вернемся к указателю point_to_Object типа А*, который ссылается на объект object_В типа В*. Давайте внимательно посмотрим на оператор, который вызывает виртуальную функцию v_function()для объекта, на который указывает point_to_Object .

A *point_to_Object; // объявим указатель на базовый класс
point_to_Object=&object_B; //присвоим указателю адрес объекта В
point_to_Object->;v_function(); //вызовем функцию

Указатель point_to_Object может хранить адрес объекта типа А или В. Значит во время выполнения этот оператор point_to_Object-gt;v_function(); вызывает виртуальную функцию класса на объект которого он в данный момент ссылается. Если point_to_Object ссылается на объект типа А, вызывается функция, принадлежащая классу А. Если point_to_Object ссылается на объект типа В, вызывается функция, принадлежащая классу В. Итак, один и тот же оператор вызывает функцию класса адресуемого объекта. Это и есть действие, определяемое во время выполнения программы.

Ну и что нам это дает?

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

Классический пример (по моему опыту - в 90% всей литературы по С++), который приводят в этих целях - написание графической программы. Строится иерархия классов, что-то типа "точка -gt; линия -gt; плоская фигура -gt; объемная фигура". И рассматривается виртуальная функция, скажем, Draw(), которая рисует все это... Скучно!

Давайте рассмотрим менее академичный, но все же графический пример. (Классика! Куда от нее деться?). Попробуем рассмотреть гипотетически принцип, который может быть заложен в компьютерную игру. И не просто в игру, а в основу любого (не важно 3D или 2D, крутого или так себе) шутера. Стрелялки, проще говоря. Я не кровожаден по жизни, но, грешен, люблю иногда постреляться!

Итак, мы задумали сделать крутой шутер. Что понадобиться в первую очередь? Конечно же оружие! (Ну, пусть не в первую. Не важно.) В зависимости от того, на какую тему будем сочинять, такое оружие и понадобится. Может это будет набор от простой дубины до арбалета. Может от аркебуза до гранатомета. А может и вовсе от бластера до дезинтегратора. Скоро мы увидим, что это-то как раз и не важно.

Что же, раз есть такая масса возможностей, надо завести базовый класс.

class Weapon
{
public:
... //тут будут данные-члены, которыми может описываться, например, как
//толщина дубины, так и количество гранат в гранатомете
//эта часть для нас не важна

virtual void Use1(void);//обычно - левая кнопка мыши
virtual void Use2(void);//обычно - правая кнопка мыши

... //тут будут еще какие-то данные-члены и методы
};

Не вдаваясь в подробности этого класса, можно сказать, что самыми важными, пожалуй, будут функции Use1() и Use2(), которые описывают поведение (или применение) этого оружия. От этого класса можно порождать любые виды вооружения. Будут добавляться новые данные-члены (типа количества патронов, скорострельности, уровня энергии, длинны лезвия и т.п.) и новые функции. А переопределяя функции Use1() и Use2(), мы будем описывать различие в применении оружия (для ножа это может быть удар и метание, для автомата - стрельба одиночными и очередями).

Коллекцию вооружения надо где-то хранить. Видимо, проще всего организовать для этого массив указателей типа Weapon*. Для простоты предположим, что это глобальный массив Arms, на 10 видов оружия, и все указатели для начала инициализированы нулем.

Weapon *Arms; //массив указателей на объекты типа Weapon

Создавая в начале программы динамические объекты-виды оружия, будем добавлять указатели на них в массив.

Для того чтобы указать, какое оружие находится в пользовании, заведем переменную-индекс массива, значение которой будем изменять в зависимости от выбранного вида оружия.

int TypeOfWeapon;

В результате этих усилий, код, описывающий применение оружия в игре может выглядеть, например, так:

if(LeftMouseClick) Arms-gt;Use1();
else Arms->Use2();

Все! Мы создали код, который описывает стрельбу-пальбу-войну еще до того, как решили, какие типы оружия будут использоваться. Более того. У нас вообще еще нет ни одного реального типа вооружения! Дополнительная (иногда очень важная) выгода - этот код можно будет скомпилировать отдельно и хранить в библиотеке. В дальнейшем вы (или другой программист) можете вывести новые классы из Weapon, сохранить их в массиве Arms и использовать. При этом не потребуется перекомпиляции вашего кода.

Особо заметьте, что этот код не требует от вас точного задания типов данных объектов на которые ссылаются указатели Arms, требуется только, чтобы они были производными от Weapon. Объекты определяют во время выполнения, какую функцию Use() им следует вызвать.

Некоторые тонкости применения

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

Вернемся к началу - к скучным классам А, В и С. Класс С на данный момент стоит у нас в самом низу иерархии, в конце линии наследования. В классе С точно также можно определить замещающую виртуальную функцию. Причем применять ключевое слово virtual совсем необязательно, поскольку это конечный класс в линии наследования. Функция и так будет работать и выбираться как виртуальная. Но! А вот если вам приспичит вывести некий класс D из класса С, да еще и изменить поведение функции v_function(), то тут как раз ничего и не выйдет. Для этого в классе С функция v_function() должна быть объявлена, как virtual. Отсюда правило, которое можно сформулировать так: "единожды виртуальный - всегда виртуальный!". То есть, ключевое слово virtual лучше не отбрасывать - вдруг пригодится?

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

Далее. Если в производном классе ввести функцию с тем же именем и типом возвращаемого значения, что и виртуальная функция базового класса, но с другим набором параметров, то эта функция производного класса уже не будет виртуальной. Даже если вы сопроводите ее ключевым словом virtual, она не будет тем, что вы ожидали. В этом случае с помощью указателя на базовый класс при любом значении этого указателя будет выполняться обращение к функции базового класса. Вспомните правило о перегрузке функций! Это просто разные функции. У вас получится совсем другая виртуальная функция. Вообще говоря подобные ошибки весьма трудноуловимы, поскольку обе формы записи вполне допустимы и надеяться на диагностику компилятора в этом случае не приходится.

Отсюда еще одно правило. При замещении виртуальных функций требуется полное совпадение типов параметров, имен функций и типов возвращаемых значений в базовом и производном классах.

И еще. Виртуальной функцией может быть только нестатическая компонентная функция класса. Виртуальной не может быть глобальная функция. Виртуальная функция может быть объявлена дружественной (friend) в другом классе. Но о дружественных функциях мы поговорим как-нибудь в другой статье.

Вот, собственно, и все на этот раз.

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

Если у вас есть вопросы - пишите, будем разбираться.

Чисто виртуальные функции

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

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

Виртуальными могут быть не любые функции, а только нестатические компонентные функции какого-либо класса. После того как функция определена как виртуальная, ее повторное определение в производном классе (с тем же самым прототипом) создает в этом классе новую виртуальную функцию, причем спецификатор virtual может не использоваться.

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

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

Методы(функции)

Виртуальные методы объявляются в базовом классе с ключевым словом virtual, а в производном классе могут быть переопределены. Прототипы виртуальных методов как в базовом, так и в производном классе должны быть одинаковы.

Применение виртуальных методов позволяет реализовывать механизм позднего связывания, при котором определение вызываемого метода происходит на этапе выполнения, а не на этапе компиляции. При этом вызываемый виртуальный метод зависит от типа объекта, для которого он вызывается. При раннем связывании, используемом для не виртуальных методов, определение вызываемого метода происходит на этапе компиляции.

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

При вызове метода с использованием указателя на класс действуют следующие правила:

• для виртуального метода вызывается метод, соответствующий типу объекта, на который указывает указатель.
• для не виртуального метода вызывается метод, соответствующий типу самого указателя.

В следующем примере иллюстрируется вызов виртуальных методов:

Class A // Объявление базового класса{ public: virtual void VirtMetod1(); // Виртуальный метод void Metod2(); // Не виртуальный метод};void A::VirtMetod() { cout << "Вызван A::VirtMetod1\n";} void A::Metod2() { cout << "Вызван A::Metod2\n"; } class B: public A // Объявление производного класса{public: void VirtMetod1(); // Виртуальный метод void Metod2(); // Не виртуальный метод};void B::VirtMetod1() { cout << "B::VirtMetod1\n";}void B::Metod2() { cout << "B::Metod2\n"; }void main() { B aB; // Объект класса B B *pB = &aB; // Указатель на объект класса B A *pA = &aB; // Указатель на объект класса A pA->VirtMetod1(); // Вызов метода VirtMetod класса B pB->VirtMetod1(); // Вызов метода VirtMetod класса B pA->Metod2(); // Вызов метода Metod2 класса A pB->Metod2(); // Вызов метода Metod2 класса B}

Результатом выполнения этой программы будут следующие строки:

Вызван B::VirtMetod1Вызван B::VirtMetod1Вызван A::Metod2Вызван B::Metod2

Чисто виртуальной функцией называется виртуальная функция, указанная с инициализатором

Например:

Virtual void F1(int) =0;

Объявление класса может содержать виртуальный деструктор, используемый для удаления объекта определенного типа. Однако виртуального конструктора в языке С++ не существует. Некоторой альтернативой, позволяющей создавать объекты заданного типа, могут служить виртуальные методы, в которых выполняется вызов конструктора для создания объекта данного класса.

Очередная модификация базового класса приводит к неожиданным последствиям. Эта модификация состоит в изменении спецификатора функции-члена базового класса. Мы (впервые!) используем спецификатор virtual в объявлении функции. Функции, объявленные со спецификатором virtual, называются виртуальными функциями. Введение виртуальных функций в объявление базового класса (всего лишь один спецификатор) имеет столь значительные последствия для методологии объектно-ориентированного программирования, что мы лишний раз приведём модифицированное объявление класса A:

Class A { public: virtual int Fun1(int); };

Один дополнительный спецификатор в объявлении функции и больше никаких (пока никаких) изменений в объявлениях производных классов. Как всегда, очень простая функция main(). В ней мы определяем указатель на объект базового класса, настраиваем его на объект производного типа, после чего по указателю мы вызываем функцию Fun1():

Void main () { A *pObj; A MyA; AB MyAB; pObj = &MyA; pObj->Fun1(1); AC MyAC; pObj = &MyAC; pObj->Fun1(1); }

Если бы не спецификатор virtual, результат выполнения выражения вызова

PObj->Fun1(1);

был бы очевиден: как известно, выбор функции определяется типом указателя.

Однако спецификатор virtual меняет всё дело. Теперь выбор функции определяется типом объекта, на который настраивается указатель базового класса. Если в производном классе объявляется нестатическая функция, у которой имя, тип возвращаемого значения и список параметров совпадают с аналогичными характеристиками виртуальной функции базового класса, то в результате выполнения выражения вызова вызывается функция-член производного класса.

Сразу надо заметить, что возможность вызова функции-члена производного класса по указателю на базовый класс не означает, что появилась возможность наблюдения за объектом "сверху вниз" из указателя на объект базового класса. Невиртуальные функции-члены и данные по-прежнему недоступны. И в этом можно очень легко убедиться. Для этого достаточно попробовать сделать то, что мы уже однажды проделали - вызвать неизвестную в базовом классе функцию-член производного класса:

//pObj->Fun2(2); //pObj->AC::Fun1(2);

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

Наличие этих самых таблиц виртуальных функций можно попытаться обнаружить с помощью операции sizeof. Конечно, здесь всё зависит от конкретной реализации, но, по крайней мере, в версии Borland C++ объект-представитель класса, содержащего объявления виртуальных функций, занимает больше памяти, нежели объект аналогичного класса, в котором те же самые функции объявлены без спецификатора virtual.

Cout << "Размеры объекта: " << sizeof(MyAC) << "…" << endl;

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

MyAC::= vptr A AC vtbl::= &AC::Fun1

На нашей новой схеме объекта указатель на таблицу (массив из одного элемента) виртуальных функций не случайно отделён от фрагмента объекта, представляющего базовый класс лишь пунктирной линией. Он находится в поле зрения этого фрагмента объекта. Благодаря доступности этого указателя оператор вызова виртуальной функции Fun1

PObj->Fun1(1);

можно представить следующим образом:

(*(pObj->vptr)) (pObj,1);

Здесь только на первый взгляд всё запутано и непонятно. На самом деле, в этом операторе нет ни одного не известного нам выражения.

Здесь буквально сказано следующее:

ВЫЗВАТЬ ФУНКЦИЮ, РАСПОЛОЖЕННУЮ ПО НУЛЕВОМУ ИНДЕКСУ ТАБЛИЦЫ ВИРТУАЛЬНЫХ ФУНКЦИЙ vtbl (в этой таблице у нас всего один элемент), АДРЕС НАЧАЛА КОТОРОЙ МОЖНО НАЙТИ ПО УКАЗАТЕЛЮ vptr.

В СВОЮ ОЧЕРЕДЬ, ЭТОТ УКАЗАТЕЛЬ ДОСТУПЕН ПО УКАЗАТЕЛЮ pObj, НАСТРОЕННОМУ НА ОБЪЕКТ MyAC. ФУНКЦИИ ПЕРЕДАЁТСЯ ДВА (!) ПАРАМЕТРА, ПЕРВЫЙ ИЗ КОТОРЫХ ЯВЛЯЕТСЯ АДРЕСОМ ОБЪЕКТА MyAC (значение для this указателя!), ВТОРОЙ - ЦЕЛОЧИСЛЕННЫМ ЗНАЧЕНИЕМ, РАВНЫМ 1.

Вызов функции-члена базового класса обеспечивается посредством квалифицированного имени.

PObj->A::Fun1(1);

В этом операторе мы отказываемся от услуг таблицы виртуальных функций. При этом мы сообщаем транслятору о намерении вызвать функцию-член базового класса. Механизм поддержки виртуальных функций строг и очень жёстко регламентирован. Указатель на таблицу виртуальных функций обязательно включается в самый "верхний" базовый фрагмент объекта производного класса. В таблицу указателей включаются адреса функций-членов фрагмента самого "нижнего" уровня, содержащего объявления этой функции.

Мы в очередной раз модифицируем объявление классов A, AB и объявляем новый класс ABC.

Модификация классов A и AB сводится к объявлению в них новых функций-членов:

Class A { public: virtual int Fun1(int key); virtual int Fun2(int key); }; ::::: int A::Fun2(int key) { cout << " Fun2(" << key << ") from A " << endl; return 0; } class AB: public A { public: int Fun1(int key); int Fun2(int key); }; ::::: int AB::Fun2(int key) { cout << " Fun2(" << key << ") from AB " << endl; return 0; } Класс ABC является производным от класса AB: class ABC: public AB { public: int Fun1(int key); }; int ABC::Fun1(int key) { cout << " Fun1(" << key << ") from ABC " << endl; return 0; }

В этот класс входит объявление функции-члена Fun1, которая объявляется в косвенном базовом классе A как виртуальная функция. Кроме того, этот класс наследует от непосредственной базы функцию-член Fun2. Эта функция также объявляется в базовом классе A как виртуальная. Мы объявляем объект-представитель класса ABC:

ABC MyABC;

Его схему можно представить следующим образом:

MyABC::= vptr A AB ABC vtbl::= &AB::Fun2 &ABC::Fun1

Таблица виртуальных функций сейчас содержит два элемента. Мы настраиваем указатель на объект базового класса на объект MyABC, затем вызываем функции-члены:

PObj = &MyABC; pObj->Fun1(1); pObj->Fun2(2);

В этом случае невозможно вызвать функцию-член AB::Fun1(), поскольку её адрес не содержится в списке виртуальных функций, а с верхнего уровня объекта MyABC, на который настроен указатель pObj, она просто не видна. Таблица виртуальных функций строится конструктором в момент создания объекта соответствующего объекта. Безусловно, транслятор обеспечивает соответствующее кодирование конструктора. Но транслятор не в состоянии определить содержание таблицы виртуальных функций для конкретного объекта. Это задача времени исполнения. Пока таблица виртуальных функций не будет построена для конкретного объекта, соответствующая функция-член производного класса не сможет быть вызвана. В этом легко убедиться, после очередной модификации объявления классов.

Программа невелика, поэтому имеет смысл привести её текст полностью. Не следует обольщаться по поводу операции доступа к компонентам класса::. Обсуждение связанных с этой операцией проблем ещё впереди.

#include class A { public: virtual int Fun1(int key); }; int A::Fun1(int key) { cout << " Fun1(" << key << ") from A." << endl; return 0; } class AB: public A { public: AB() {Fun1(125);}; int Fun2(int key); }; int AB::Fun2(int key) { Fun1(key * 5); cout << " Fun2(" << key << ") from AB." << endl; return 0; } class ABC: public AB { public: int Fun1(int key); }; int ABC::Fun1(int key) { cout << " Fun1(" << key << ") from ABC." << endl; return 0; } void main () { ABC MyABC; // Вызывается A::Fun1(). MyABC.Fun1(1); // Вызывается ABC::Fun1(). MyABC.Fun2(1); // Вызываются AB::Fun2() и ABC::Fun1(). MyABC.A::Fun1(1); // Вызывается A::Fun1(). A *pObj = &MyABC; // Определяем и настраиваем указатель. cout << "==========" << endl; pObj->Fun1(2); // Вызывается ABC::Fun1(). //pObj->Fun2(2); // Эта функция через указатель недоступна!!! pObj->A::Fun1(2); // Вызывается A::Fun1(). }

Теперь в момент создания объекта MyABC

ABC MyABC;

из конструктора класса AB (а он вызывается раньше конструктора класса ABC), будет вызвана функция A::Fun1(). Эта функция является членом класса A. Объект MyABC ещё до конца не сформирован, таблица виртуальных функций ещё не заполнена, о существовании функции ABC::Fun1() ещё ничего не известно. После того, как объект MyABC будет окончательно сформирован, таблица виртуальных функций заполнится, а указатель pObj будет настроен на объект MyABC, вызов функции A::Fun1() через указатель pObj будет возможен лишь с использованием полного квалифицированного имени этой функции:

PObj->Fun1(1); // Это вызов функции ABC::Fun1()! pObj->A::Fun1(1); // Очевидно, что это вызов функции A::Fun1()!

Заметим, что вызов функции-члена Fun1 непосредственно из объекта MyABC приводит к аналогичному результату:

MyABC.Fun1(1); // Вызов функции ABC::Fun1().

А попытка вызова невиртуальной функции AB::Fun2() через указатель на объект базового класса заканчивается неудачей. В таблице виртуальных функций адреса этой функции нет, а с верхнего уровня объекта "посмотреть вниз" невозможно.

//pObj->Fun2(2); // Так нельзя!

Результат выполнения этой программки наглядно демонстрирует специфику использования виртуальных функций. Всего несколько строк…

Fun1(125) from A. Fun1(1) from ABC. Fun1(5) from ABC. Fun2(1) from AB. Fun1(1) from A. ========== Fun1(2) from ABC. Fun1(2) from A.

Один и тот же указатель в ходе выполнения программы может настраиваться на объекты-представители различных производных классов. В результате в буквальном смысле одно и то выражение вызова функции-члена обеспечивает выполнение совершенно разных функций. Впервые мы сталкиваемся с так называемым ПОЗДНИМ или ОТЛОЖЕННЫМ СВЯЗЫВАНИЕМ.

Заметим, что спецификация virtual относится только к функциям. Виртуальных данных-членов не существует. Это означает, что не существует возможности обратиться к данным-членам объекта производного класса по указателю на объект базового класса, настроенному на объект производного класса.

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

И ещё один маленький пример, демонстрирующий изменение поведение объекта-представителя производного класса после того, как одна из функция базового класса становится виртуальной.

#include class A { public: void funA () {xFun();}; /*virtual*/void xFun () {cout <<"this is void A::xFun();"<< endl;}; }; class B: public A { public: void xFun () {cout <<"this is void B::xFun ();"<

В начале спецификатор virtual а определении функции A::xFun() закомментирован. Процесс выполнения программы состоит в определении объекта-представителя objB производного класса B и вызова для этого объекта функции-члена funA(). Эта функция наследуется из базового класса, она одна и очевидно, что её идентификация не вызывает у транслятора никаких проблем. Эта функция принадлежит базовому классу, а это означает, что в момент её вызова, управление передаётся "на верхний уровень" объекта objB. На этом же уровне располагается одна из функций с именем xFun(), и именно этой функции передаётся управление в ходе выполнения выражения вызова в теле функции funA(). Мало того, из функции funA() просто невозможно вызвать другую одноименную функцию. В момент разбора структуры класса A транслятор вообще не имеет никакого представления о структуре класса B. Функция xFun() - член класса B оказывается недостижима из функции funA().

Но если раскомментировать спецификатор virtual в определении функции A::xFun(), между двумя одноименными функциями установится отношение замещения, а порождение объекта objB будет сопровождаться созданием таблицы виртуальных функций, в соответствии с которой будет вызываться замещающая функция член класса B. Теперь для вызова замещаемой функции необходимо использовать её квалифицированное имя:

Void A::funA () { xFun(); A::xFun(); }

Виртуальная функция

Виртуальный метод (виртуальная функция ) - в объектно-ориентированном программировании метод (функция) класса , который может быть переопределён в классах-наследниках так, что конкретная реализация метода для вызова будет определяться во время исполнения. Таким образом, программисту необязательно знать точный тип объекта для работы с ним через виртуальные методы: достаточно лишь знать, что объект принадлежит классу или наследнику класса, в котором метод объявлен.

Виртуальные методы - один из важнейших приёмов реализации полиморфизма . Они позволяют создавать общий код, который может работать как с объектами базового класса, так и с объектами любого его класса-наследника. При этом, базовый класс определяет способ работы с объектами и любые его наследники могут предоставлять конкретную реализацию этого способа. В некоторых языках программирования , например в с англ. pure virtual ) или абстрактными. Класс, содержащий хотя бы один такой метод, тоже будет абстрактным . Объект такого класса создать нельзя (в некоторых языках допускается, но вызов абстрактного метода приведёт к ошибке). Наследники абстрактного класса должны предоставить реализацию для всех его абстрактных методов, иначе они, в свою очередь, будут абстрактными классами.

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

Пример

Пример виртуальной функции в Delphi

Достаточно часто виртуальные методы забывают перекрыть с помощью ключевого слова override . Это приводит к закрытию метода. В этом случае замещения методов в VMT не произойдет и требуемая функциональность не будет получена.

Эта ошибка отслеживается компилятором, который выдаёт соответствующее предупреждение.

Вызов метода предка из перекрытого метода

Бывает необходимо вызвать метод предка в перекрытом методе.

Объявим два класса. Предка(Ancestor):

TAncestor = class private protected public {Виртуальная процедура.} procedure VirtualProcedure; virtual; end;

и его потомка (Descendant):

TDescendant = class (TAncestor) private protected public {Перекрытие виртуальной процедуры.} procedure VirtualProcedure; override; end;

Обращение к методу предка реализуется с помощью ключевого слова ""inherited""

procedure TDescendant.VirtualProcedure; begin inherited; end;

Стоит помнить, что в Delphi, деструктор должен быть обязательно перекрытым. ""override""; и содержать вызов деструктора предка

TDescendant = class (TAncestor) private protected public destructor Destroy; override; end; destructor TDescendant. Destroy; begin inherited; end;

В языке C++, не нужно вызывать конструктор и деструктор предка, деструктор должен быть виртуальным. Деструкторы предков вызовутся автоматически. Чтобы вызвать метод предка, нужно явно вызвать метод:

Class Ancestor { public : virtual void function1 () { printf ("Ancestor::function1" ) ; } } ; class Descendant: public Ancestor { public : virtual void function1 () { printf ("Descendant::function1" ) ; Ancestor::function1 () ; // this will print the text "Ancestor::function1" } } ;

Для вызова конструктора предка нужно указать конструктор:

Class Descendant: public Ancestor { public : Descendant() : Ancestor() ; } ;

См. также

Ссылки

• C++ FAQ Lite: Виртуальные функции в C++ (англ.)

Wikimedia Foundation . 2010 .

Начну с повторения: вы не должны вызывать виртуальные функции во время работы конструкторов или деструкторов, потому что эти вызовы будут делать не то, что вы думаете, и результатами их работы вы будете недовольны. Если вы – программист на Java или C#, то обратите на это правило особое внимание, потому что это в этом отношении C++ ведет себя иначе.

Предположим, что имеется иерархия классов для моделирования биржевых транзакций, то есть поручений на покупку, на продажу и т. д. Важно, чтобы эти транзакции было легко проверить, поэтому каждый раз, когда создается новый объект транзакции, в протокол аудита должна вноситься соответствующая запись. Следующий подход к решению данной проблемы выглядит разумным:

class Transaction { // базовый класс для всех

public: // транзакций

virtual void logTransaction() const = 0; // выполняет зависящую от типа

// запись в протокол

Transaction::Transaction() // реализация конструктора

{ // базового класса

logTransaction();

class BuyTransaction: public Transaction { // производный класс

// транзакции данного типа

class SellTransaction: public Transaction { // производный класс

virtual void logTransaction() const = 0; // как протоколировать

// транзакции данного типа

Посмотрим, что произойдет при исполнении следующего кода:

BuyTransaction b;

Ясно, что будет вызван конструктор BuyTransaction, но сначала должен быть вызван конструктор Transaction, потому что части объекта, принадлежащие базовому классу, конструируются прежде, чем части, принадлежащие производному классу. В последней строке конструктора Transaction вызывается виртуальная функция logTransaction, тут-то и начинаются сюрпризы. Здесь вызывается та версия logTransaction, которая определена в классе Transaction, а не в BuyTransaction, несмотря на то что тип создаваемого объекта – BuyTransaction. Во время конструирования базового класса не вызываются виртуальные функции, определенные в производном классе. Объект ведет себя так, как будто он принадлежит базовому типу. Короче говоря, во время конструирования базового класса виртуальных функций не существует.

Есть веская причина для столь, казалось бы, неожиданного поведения. Поскольку конструкторы базовых классов вызываются раньше, чем конструкторы производных, то данные-члены производного класса еще не инициализированы во время работы конструктора базового класса. Это может стать причиной неопределенного поведения и близкого знакомства с отладчиком. Обращение к тем частям объекта, которые еще не были инициализированы, опасно, поэтому C++ не дает такой возможности.

Есть даже более фундаментальные причины. Пока над созданием объекта производного класса трудится конструктор базового класса, типом объекта является базовый класс. Не только виртуальные функции считают его таковым, но и все прочие механизмы языка, использующие информацию о типе во время исполнения (например, описанный в правиле 27 оператор dynamic_cast и оператор typeid). В нашем примере, пока работает конструктор Transaction, инициализируя базовую часть объекта BuyTransaction, этот объект относится к типу Transaction. Именно так его воспринимают все части C++, и в этом есть смысл: части объекта, относящиеся к BuyTransaction, еще не инициализированы, поэтому безопаснее считать, что их не существует вовсе. Объект не является объектом производного класса до тех пор, пока не начнется исполнение конструктора последнего.

То же относится и к деструкторам. Как только начинает исполнение деструктор производного класса, предполагается, что данные-члены, принадлежащие этому классу, не определены, поэтому C++ считает, что их больше не существует. При входе в деструктор базового класса наш объект становится объектом базового класса, и все части C++ – виртуальные функции, оператор dynamic_cast и т. п. – воспринимают его именно так.

В приведенном выше примере кода конструктор Transaction напрямую обращается к виртуальной функции, что представляет собой откровенное нарушение принципов, описанных в данном правиле. Это нарушение легко обнаружить, поэтому некоторые компиляторы выдают предупреждение (а другие – нет; дискуссию о предупреждениях см. в правиле 53). Но даже без такого предупреждения ошибка наверняка проявится до времени исполнения, потому что функция logTransaction в классе Transaction объявлена чисто виртуальной. Если только она не была где-то определена (маловероятно, но возможно – см. правило 34), то такая программа не скомпонуется: компоновщик не найдет необходимую реализацию Transaction::logTransaction.

Не всегда так просто обнаружить вызов виртуальной функции во время работы конструктора или деструктора. Если Transaction имеет несколько конструкторов, каждый из которых выполняет одну и ту же работу, то следует проектировать программу так, чтобы избежать дублирования кода, поместив общую часть инициализации, включая вызов logTransaction, в закрытую невиртуальную функцию инициализации, скажем, init:

class Transaction {

{ init(); } // вызов невиртуальной функции

Virtual void logTransaction() const = 0;

logTransaction(); // а это вызов виртуальной

// функции!

Концептуально этот код не отличается от приведенного выше, но он более коварный, потому что обычно будет скомпилирован и скомпонован без предупреждений. В этом случае, поскольку logTransaction – чисто виртуальная функция класса Transaction, в момент ее вызова большинство систем времени исполнения прервут программу (обычно выдав соответствующее сообщение). Однако если logTransaction будет «нормальной» виртуальной функцией, у которой в классе Transaction есть реализация, то эта функция и будет вызвана, и программа радостно продолжит работу, оставляя вас в недоумении, почему при создании объекта производного класса была вызвана неверная версия logTransaction. Единственный способ избежать этой проблемы – убедиться, что ни один из конструкторов и деструкторов не вызывает виртуальных функций при создании или уничтожении объекта, и что все функции, к которым они обращаются, следуют тому же правилу.

Но как вы можете убедиться в том, что вызывается правильная версия log-Transaction при создании любого объекта из иерархии Transaction? Понятно, что вызов виртуальной функции объекта из конструкторов не годится.

Есть разные варианты решения этой проблемы. Один из них – сделать функцию logTransaction невиртуальной в классе Transaction, затем потребовать, чтобы конструкторы производного класса передавали необходимую для записи в протокол информацию конструктору Transaction. Эта функция затем могла бы безопасно вызвать невиртуальную logTransaction. Примерно так:

class Transaction {

explicit Transaction(const std::string& loginfo);

void logTransaction(const std::string& loginfo) const; // теперь –

// невиртуальная

// функция

Transaction::Transaction(const std::string& loginfo)

logTransaction(loginfo); // теперь –

// невиртуальный

class BuyTransaction: public Transaction {

BuyTransaction(parameters )

: Transaction(createLogString(parameters )) // передать информацию

{...} // для записи в протокол

... // конструктору базового

static std::string createLogString(parameters );

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

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