Лекции (1129116), страница 29

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

Текст из файла (страница 29)

procedure G;

end;

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

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

type MyObj2 = class (MyObj)

procedure F; override; // убираем виртуальность

procedure G; virtual; // переопределяем как виртуальную

end;

Хотя такие трюки проделывать можно, но не нужно, и всякий раз, когда происходит такое переопределение, Delphi выдает предупреждение. Рассмотрим пример.

P : PMyObj; //Пусть PMyObj указатель на MyObj

P1 : PMyObj2;

P2 : PMyObj3; // Пусть MyObj3 выведен из MyObj2

// и в нем переопределена G с помощью слова override

P:=P2;

P1:=P2;

P^.G; // вызов G из MyObj

P^.F; // вызов F из MyObj2 (или MyObj3 если в нем F переопределена как виртуальная)

P1^.G; // вызов G из MyObj2 (или MyObj3 если в нем G переопределена как виртуальная)

P1^.F; // вызов F из MyObj3 если в нем F переопределена как виртуальная

Такие трюки дают несколько странные результаты, и поэтому большинство языков программирования запрещают такого рода финты.

Лекция 24

Динамическое связывание методов

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

Ранее мы рассмотрели это понятие на примере C++ и Oberon-2 и увидели, как работают соответствующие динамические связанные методы, в Oberon-2 это: процедуры, привязанные к типу; в C++ - виртуальные функции-члены. Безусловно, речь идет об одних и тех же понятиях.

У нас есть интерфейс, а именно:

<возвр. тип> <имя> <аргументы>

этот интерфейс неизменен, и он должен быть прописан в классе наиболее высокого уровня (необязательно в корневом). Этот интерфейс является частью класса. При этом соответствующее имя объявлено с ключевым словом virtual в C++, либо, по синтаксису отличаясь, как привязанная к типу процедура в Oberon. И далее, все наследующие классы обязаны сохранять интерфейс неизменным. Таким образом, у нас возникает несколько тел функции с одним интерфейсом. При этом какое тело будет вызвано зависит исключительно от динамического типа соответствующей переменной.

То есть в Oberon-2 тоже есть соответствующий аргумент, когда мы пишем процедуру

PROCEDURE (P: T) имя (...);

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

При этом достигается очень большая гибкость, когда мы говорили об интерфейсах графических фигур, о том, что в этот интерфейс могут входить функции Draw и Move. Схема, конечно, упрощена, но тем не менее. Должна ли быть функция Move виртуальной? Из чего состоит понятие движения графического объекта? Из того, что сначала объект стирается с экрана, а затем перерисовывается на новом месте. Если процедура отрисовки специфична, то она может выглядеть совершенно по-разному. Соответствующий класс Shape может выглядеть следующим образом:

class Shape {

int x,y;

...

virtual void Draw(bool erase); //она виртуальна, ее

//параметр говорит, что

//нужно сделать – стереть

//или нарисовать

void Move (int dx, int dy);

{ Draw (true);

x +=dx; y+=dy;

Draw (false);

}

}

Заметим, что метод Move может быть и невиртуальным, поскольку вся его специфика заключена в специфике метода Draw, который уже виртуальный. Смысла делать его виртуальным – никакого, однако, он сам вызывает виртуальный метод. Если мы будем вызывать:

Shape *p;

p->Move(1,1);

совершенно понятно, что будет вызвана конкретная функция Move для класса Shape, но она уже, в свою очередь, вызовет виртуальный метод Draw, конкретизация которого зависит от динамического типа p, то есть Draw будет вызван нужный, причем сделано это будет без участия программиста, в том плане, что не нужно никого никуда присваивать, писать сложные конструкции и т.д. И вообще, ООП не может быть без виртуальных методов или их аналогов. Более того, что в чистых объектно-ориентированных языках (заметим, что C++ сюда не относится), например, Java и Smalltalk нет невиртуальных методов, любой вызов метода зависит от динамического типа объекта. Понятно, что в C++ невиртуальные методы сделаны исключительно из совместимости с С. Хотелось, чтобы текст, написанный на С, по-крайне мере по распределению памяти совпадал с тем, что будет понято компилятором C++. Например:

class Complex {

...

};

в этом классе (или структуре с точки зрения C) нет ничего динамического. Поэтому Страуструп ввел два вида методов – виртуальные и невиртуальные.

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

Рассмотрим вырожденный пример:

То, что у нас функции g ( ) в обоих классах имеют одинаковый интерфейс значения не имеет, так как компилятор определеяет вызов соответствующего метода статически, если указатель описан класса X, то будет вызвана g( ) из класса X, причем динамический тип объекта не важен (он может быть и Y). В то же время для f и h это уже будет не так. Заметим, что в описании Y писать virtual для f и h уже необязательно – это свойство установлено выше в X и снять его уже никак нельзя, интерфейсы всех виртуальных одноименных функций обязаны быть одинаковыми, иначе функция будет перегружена (о чем, возможно, скажет компилятор, однако ошибки в этом нет).

Вспомним пример из предыдущей лекции:

X *px = new X;

Y *py = new Y;

px->f( ); //X::f( )

px->g( ); //X::g( )

py->f( ); //Y::f( )

py->g( ); //Y::g( )

px=py;

px->f( ); //Y::f( )

px->g( ); //X::g( )

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

Как же это все реализуется? Для каждого класса существует табличка, которая называется Таблицей Виртуальных Методов. Она существует для каждого класса, у которого есть виртуальные методы (они могут быть унаследованы или созданы). Как только появляется в классе виртуальный метод, то компилятор генерирует ТВМ. Она состоит из указателей на конкретные виртуальные методы (она инициализируется в момент загрузки программы). Для X ТВМ будет выглядеть следующим образом:

Для Y:

Представим, что у нас есть третий класс Z, в нем мы одну функцию переопределим, а одну добавим:

class Z public Y {

void f ( ); int c;

virtual i( );

};

Заметим, что функции h( ) в Z нет, она будет унаследована от Y. Для Z ТВМ:

ТВМ создаются таким образом, что порядок всех определенных функций у класса одной цепочки наследования – одинаков. То есть смещения виртуальных функций в ТВМ для всех таких классов – одинаковы: f( ) имеет смещение 0, h( ) - +1, если появляются новые, то они добавляются далее. И любой класс-наследник получит эту таблицу именно с таким порядком.

Каков же вид объекта? Его структура становится следующей (учитывая то, что следует указывать для класса его ТВМ):

X:

Y:

Z:

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

PX = new X;

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

Если, например, было присваивание:

px=py,

то для px картина теперь выглядит так::

Нижнюю часть (переменную b) мы, вообще говоря, не видим, но это и неважно. Важно то, что теперь по нулевому смещению стоит ссылка на ТВМ Y, а значит все виртуальные функции исполняются так, как они прописаны в ТВМ Y.

Рассмотрим ситуацию при

px=pz;

px->h;

При px->h будет вызвана функция Y::h(), так как именно она прописана в ТВМ Z (она наследуется Z от Y).

Указатель на ТВМ и есть информация о динамическом типе. Заметим, что ТВМ может содержать и бОльшую информацию, например, название типа. Но главное все-таки и обязательное – это таблица функций.

C++

В C++ виртуальные методы реализованы по такой схеме, и эта схема проста. В частности, виртуальный метод вызывается за, примерно, 7 ассембелрных команд (невиртуальный – за одну).

Чем еще неявно пользуется компилятор? Тем, что ссылка на ТВМ всегда занимает одно и то же место.

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

• По памяти. На первый взгляд они небольшие – по одной ТВМ на каждый тип, с другой стороны, мы в объект каждого класса теперь должны добавлять указатель (если в классе есть виртуальные методы).

• По времени. На выполнение тех 7 команд, о которых было упомянуто выше.

Е
ще приятно то, что в случае единичного наследования компилятор знает, какой указатель передавать. Но ситуация меняется кардинально в случае множественного наследования. Страуструпу удалось реализовать множественное наследование достаточно эффективно, хотя это было непросто. Пусть у нас есть два класса: X, Y и наследуемый от них Z.

Тут возникает некоторая неприятность. Как выглядит Z, если забыть о виртуальных функциях? Часть от X, часть от Y, часть своя.

Заметим, что функция g( ) в Z не переопределяется. Пусть у нас есть такая ситуация:

X *px, Y *py, Z *pz;

px=new X; py=new Y; pz=new Z;

теперь сделаем следующее:

px=pz;

px->f( );//будет вызвана Z::f( ), поскольку она переопределяется в Z.

px->g( );//компилятор скажет «имя неопределено», так как функция g( )

// присутствует и в X и в Y, поэтому нам следует явным образом

// указывать, какая функция вызывается – X::g( ), например. Это

// снимает принцип виртуальности.

Теперь представим себе такую ситуацию:

т
огда в ситуации:

px=pz;

px->f( ) // X::f( )

Характеристики

Список файлов лекций