Б. Страуструп - Язык программирования С++. Специальное издание, 3-изд. Бином. 2004 (1160791), страница 77
Текст из файла (страница 77)
) Это определение содержит три ошибки: не вызывается конструктор Етр1оуее и дважды осушествляется попытка инициализации членов Етр1оуее непосредственно. Объекты класса создаются снизу-вверх: сначала базовый класс, потом члены и затем сам производный класс. Онн уничтожаются в противоположном порядке: сначала производный класс, члены, а затем базовый класс. Члены иподобъекты базовых классов конструируются в порядке их объявления в классе и уничтожаются в обратном порядке. Сы. также !) 10.4.6 и з 15.2.4.1.
12.2.3. Копирование Копирование объектов класса определяется копируюшими конструктором и опера- торами присваивания (6 10.4,4.1). Рассмотрим пример: с(озз Етр1оуее ( //" Етр(оуеей орега!ог+ (соле!Етр1оуеей) Етр! о уее (сопз1 Етр! оуе ей) оо!д/(соле!Мапауегй т( ( Етр!оуее е = т; //создание е из Егпр!оуее-части т в= пи // присвоить Етр!оуее-чистын переменной е Так как копирующая функция Етр1оуее ничего не знает о Малауег копируется только Етр1оуее-часть Мапауег. Этот эффект часто называют срезкой; он нередко приводит к ошибкам и чреват сюрпризами. Одной из причин передачи указателей и ссылок на ооъекты в иерархии является желание избежать срез ки.
Другими причинами являются обеспечение полиморфного поведения Я 2.5А, () 12.2,6) и эффективности. Заметьте, что если вы не определите оператор копирующего присваивания, он булет сгенерирован компилятором Я 11.7). Отсюда следует, что операторы присваивания не наследуются.
Конструкторы никогда не наследуются. 12.2.4. Иерархия классов !1роизводный класс, в свою очередь, сам может быть базовым классом. Например: с1аззЕтр!оуее(/*... */); с!аззМапауег: рибвсЕтр1оуее(/*.„*/); с! азз 21!гес!ог . рибус Малауег ( /* ... '/ ); Такой набор связанных классов традиционно называется иерархией классов. Иерархия, в болыпинстве случаев, является деревом, но она может иметь н более общую структуру графа. Например: с1азз зетрогагу (/*...
'/); // вреиенний сотрудник Глава 12. Производные классы 356 с!асс Вессс!агу: риЬйсЕтр1оуее ( /' ... */); //секретарь с!аьв Твес;риЫ(с Тетрогагу, риЫлс Бесгегагу ( /' ... '/); с!авв Сопли)гап1: риЫ!с Тетрогагу, риЫлсМапауег(/" ... '/); // временный секретарь // врелленньи! консульлпант Или в графическом виде: ел!у Те тр о гагу Сипаи)1ап1 Таким образом на С++ можно выразить направленный ациклический (то есть не со- держащий циклов) граф классов. Подробнее ем. в ~ 15.2.
12.2.5. Поля типа вггис1Етр1оуее ( епит Етр! 1уре(М, Е); Етр! 1уре 1уре; Етр!оуее (): 1уре (Е] () О тип сотрудника: л!енеджер или нет // по уллолнаникл — не менеджер Для того чтобы использовать производные классы в качестве чего-то большего, чем просто удобного сокрашения объявления, мы должны решить следующую пробле- му: есть указатель типа Ьаве*; какому производному типу на самом деле принадле- жит объект, на который он указывает? Существует четыре фундаментальных реше- ния этой проблемы: [1] Гарантировать, что ссылки осущестнляются только на объекты одного типа Я 2.7 и глава 13).
[2] Поместить поле с информацией о типе (поле типа) в базовый класс, чтобы заинтересованныс функции могли его проверять, [3] Использовать динамическое преобразование типа (л/упат1с сав1) (5 15 4.2, (! 15.4.5). [4] Использовать виртуальные функции. Указатели на базовые классы обычно используются при проектировании классов-кон- тейнеров, таких как множества, вектора и списки. В подобных случаях решение [1] приведет к однородному списку, то есть списку объектов одного типа.
Решениями [2], [3] и [4] можно пользоваться для построения разнородных списков, то есть списков, хранящих (указатели на) объекты нескольких различных типов. Решение [3] является вариантом решения [2], возможным прн непосредственной поддержке со стороны язы- ка. Решение [4] является специальным вариантом решения [2], безопасным с точки зрения типов.
Комбинации решений [1] и [4] весьма мощны и очень интересны; почти во всех ситуациях они приводят к более ясному коду, чем [2] и [3]. Давайте сначала рассмотрим простое решение [2] с полем типа для того, чтобы понять, почему в большинстве случаен его стоит избегать. 11ример менеджер/сотруд- ник можно заместить следующим образом: 357 12,2.
Производные классы кгг!пу/(гк1 пате,~ат!1у пате; сйагтгсЫ!е 1п11!а1; Ра1е 1иг!пу с1аге; кбог1 с(ераггтеп1, к1гис1 Мапатс: риЫ1с Етр!оуее ( Мап адег () ( 1уре = М; ) // подчиненные ке1<Етр1оуее*> угоир; кбог1 1еое1; Теперь мы можем написать функцию, которая выводит информацию о любом со- труднике: ооЫрпп1 етр1оцее (сопк1Етр!оцее'е) яшйсб (е->1уре) ( саке Етр!оцее; Е. сои1 «е — >/ат!!у пате « '~!' «е->Йераггтеп1 « 'ч,п'; //- бгеаб; саке Етр1оуее: М: ( сои1 «е — >/ат!!у пате «ч1' «е->Йераг1теп1 «'чп'; //- сопя! Мапауег р = кга11с сак1<сопк1Мапауег>> (е); сои1«" 1еое1 «р->!еое1«нр'; 0- бгеа!к; Это работает прекрасно, особенно в небольшой программе, сопровождаемой одним человеком.
Однако такое решение имеет врожденный недостаток: характер зависимое~и программы от типов, с которыми манипулирует программист, таков, что компилятор не имеет возможности осуществить проверку. Обычно ситуация еще укушпается, потому что функции типа рпп1 етр1оуее () организованы так, чтобы воспользоваться общностью классов.
Например; ооиц рп'п1 етр!оуее (сопя! Етр!оуее' е) ( сои1 «е->~ат1!у пате « "ч!' «е->с!ераг1теп1 « "чп'; 0- Д' (е->1уре == етр1оуее::М) ( сопк1Мапауег' р = к1а1!с сак1<сопк1 Мапауег'> (е); сои1 « ' !еое1 ' «р — 1еие! "чп'; 358 Глава 12. Производные классы Поиск всех таких проверок поля типа, «похороненных» в большой функции, которая работает со многими производными классами, может оказаться сложной задачсй. Даже если все они найдены, бывает сложно понять, что на самом деле происходит. Более того, добавление нового производного от Етр!оуее класса подразумевает внесение изменений во все ключевые функции системы, которые содержат проверку поля типа.
Программист после внесения каких-либо изменений должен проанализировать каждую функцию, которая (хотя бы потенциально) может зависеть от проверок поля типа. Это подразумевает доступ к основным частям исходного кода и дополнительные усилия на тестирование измененного кода. Сам факт использования явного преобразования типа служит недвусмысленным указанием на то, что существует лучшее решение.
Другими словами, использование поля типа подвержено ошибкам и ведет к проблемам сопровождения, Сложности увеличиваются по мере роста программы, потому что поле типа является надругательством над идеалами модульности и сокрытия данных. Каждая функция, используюгная поле типа, должна знать о представлении и других дсталях реализации каждого класса, производного от класса с полем типа. Кроме того, складывается впечатление, что наличие любых общих данных (вроде поле типа), доступных из любого производного класса, вызывает у программистов искушение добавлять такие данные еше и еще. Общий базовый класс становится как бы хранилищем всякого рода еполезной информацииь.
Это, в свою очередь, создает нежелательные дополнительные зависимости между реализациями базового и производных классов, Ради ясности проекта и упрощения сопровождения мы хотим разделять отдельные понятия и избегать взаимозависимостей. 12.2.6. Виртуальные функции Виртуальные функции решают проблему, связанную с полем типа, предоставляя возможность программисту объявить в базовом классе функции, которые можно заместить в каждом производном классе.
Компилятор и загрузчик гарантируют правильное соответствие между объектами и функциями, применяемыми к ним. Например: е)аез Евр!оуее ( иппуу!ге! пате,(ат!!у паве; епогГ г(ераг!тепй 0- риЫ!е. Етр!оуее (еопе! егг!пуп пате, гп! г!ерГ) о!г!иа! оо!г(рпп! (! соле!; Ключевое слово и!г!иа! означает, что рг!и! (1 может действовать в качестве интерфейса как к функции рг(п! (), определенной в данном классе, так и к функции рип! !), определенной в производном классе. Если такие функции рг(л! (1 определены в производных классах, компилятор обеспечивает вызов соответствуюгцей функции рип! й для любого объекта класса, производного от Етр(оуее. Для того чтобы объявление виртуальной функции работало в качестве интерфейса к функциям, определенным в производных классах, типы аргументов функции в производном классе не должны отличаться от типов аргументов, объявленных в ба- 359 12.2.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
