Глава 7
Производные Классы
Не надо размножать объекты без необходимости
- У. Оккам
В этой главе описывается понятие производного класса в C++.
Производные классы дают простой, гибкий и эффективный аппарат
задания для класса альтернативного интерфейса и определения класса
посредством добавления возможностей к уже имеющемуся классу без
перепрограммирования или перекомпиляции. С помощью производных
классов можно также обеспечить общий интерфейс для нескольких
различных классов так, чтобы другие части программы могли работать
с объектами этих классов одинаковым образом. При этом обычно в
каждый объект помещается информация о типе, чтобы эти объекты могли
обрабатываться соответствующим образом в ситуациях, когда их тип
нельзя узнать во время компиляции. Для элегантной и надежной
обработки таких динамических зависимостей типов имеется понятие
виртуальной функции. По своей сути производные классы существуют
для того, чтобы облегчить программисту формулировку общности.
7.1 Введение
Представим себе процесс написания некоторого средства общего
назначения (например, тип связанный список, таблица имен или
планировщик для системы моделирования), которое предназначается
для использования многими разными людьми в различных
обстоятельствах. Очевидно, что в кандидатах на роль таких средств
недостатка нет, и выгоды от их стандартизации огромны. Кажется,
любой опытный программист написал (и отладил) дюжину вариантов
типов множества, таблицы имен, сортирующей функции и т.п., но
оказывается, что таблиц имен каждый программист и каждая программа
используют свою версию этих понятий, из-за чего программы слишком
трудно читать, тяжело отлаживать и сложно модифицировать. Более
того, в большой программе вполне может быть несколько копий
идентичных (почти) частей кода для работы с такими фундаментальными
понятиями.
Причина этого хаоса частично состоит в том, что представить такие
общие понятия в языке программирования сложно с концептуальной точки
зрения, а частично в том, что средства, обладающие достаточной
общностью, налагают дополнительные расходы по памяти и/или по
времени, что делает их неудобными для самых простых и наиболее
напряженно используемых средств (связанные списки, вектора и т.п.),
где они были бы наиболее полезны. Понятие производного класса в
C++, описываемое в #7.2, не обеспечивают общего решения всех этих проблем, но оно дает способ справляться с довольно небольшим числом
важных случаев. Будет, например, показано, как определить
эффективный класс общего связанного списка таким образом, чтобы все
его версии использовали код совместно.
Написание общецелевых средств - задача непростая, и часто
основной акцент в их разработке другой, чем при разработке программ
специального назначения. Конечно, нет четкой границы между
средствами общего и специального назначения, и к методам и языковым
средствам, которые описываются в этой главе, можно относиться так,
что они становятся все более полезны с ростом объема и сложности
создаваемых программ.
7.2 Производные Классы
Объекты класса конструируются снизу вверх: сначала базовый, потом
члены, а потом сам производный класс. Уничтожаются они в обратном
порядке: сначала сам производный класс, потом члены а потом
базовый.
7.2.7 Поля Типа
Чтобы использовать производные классы не просто как удобную
сокращенную запись в описаниях, надо разрешить следующую проблему:
Если задан указатель типа base*, какому производному типу в
действительности принадлежит указываемый объект? Есть три основных
способа решения этой проблемы:
[1] Обеспечить, чтобы всегда указывались только объекты одного
типа (#7.3.3);
[2] Поместить в базовый класс поле типа, которое смогут
просматривать функции; и
[3] Использовать виртуальные функции (#7.2.8).
Обыкновенно указатели на базовые классы используются при
разработке контейнерных (или вмещающих) классов: множество, вектор,
список и т.п. В этом случае решение 1 дает однородные списки, то
есть списки объектов одного типа. Решения 2 и 3 можно использовать
для построения неоднородных списков, то есть списков объектов
(указателей на объекты) нескольких различных типов. Решение 3 - это
специальный вариант решения 2, безопасный относительно типа.
Давайте сначала исследуем простое решение с помощью поля типа, то
есть решение 2. Пример со служащими и менеджерами можно было бы
переопределить так:
enum empl_type { M, E };
struct employee {
empl_type type;
employee* next;
char* name;
short department;
// ...
};
struct manager : employee {
employee* group;
short level; // уровень
};
Имея это, мы можем теперь написать функцию, которая печатает
информацию о каждом служащем:
void print_employee(employee* e)
{
switch (e->type) {
case E:
cout << e->name << "\t" << e->department << "\n";
// ...
break;
case M:
cout << e->name << "\t" << e->department << "\n";
// ...
manager* p = (manager*)e;
cout << " уровень " << p->level << "\n";
// ...
break;
}
}
и воспользоваться ею для того, чтобы напечатать список служащих:
void f()
{
for (; ll; ll=ll->next) print_employee(ll);
}
Это прекрасно работает, особенно в небольшой программе, написанной
одним человеком, но имеет тот коренной недостаток, что
неконтролируемым компилятором образом зависит от того, как
программист работает с типами. В больших программах это обычно
приводит к ошибкам двух видов. Первый - это невыполнение проверки
поля типа, второй - когда не все случаи case помещаются в
переключатель switch как в предыдущем примере. Оба избежать
достаточно легко , когда программу сначала пишут на бумаге $, но
при модификации нетривиальной программы, особенно написанной другим
человеком, очень трудно избежать и того, и другого. Часто от этих
сложностей становится труднее уберечься из-за того, что функции
вроде print() часто бывают организованы так, чтобы пользоваться
общность классов, с которыми они работают. Например:
void print_employee(employee* e)
{
cout << e->name << "\t" << e->department << "\n";
// ...
if (e->type == M) {
manager* p = (manager*)e;
cout << " уровень " << p->level << "\n";
// ...
}
}
Отыскание всех таких операторов if, скрытых внутри большой функции,
которая работает с большим числом производных классов, может
оказаться сложной задачей, и даже когда все они найдены, бывает
нелегко понять, что же в них делается.
7.2.8 Виртуальные Функции
Виртуальные функции преодолевают сложности решения с помощью
полей типа, позволяя программисту описывать в базовом классе
функции, которые можно переопределять в любом производном классе.
Компилятор и загрузчик обеспечивают правильное соответствие между
объектами и применяемыми к ним функциями. Например:
struct employee {
employee* next;
char* name;
short department;
// ...
virtual void print();
};
Ключевое слово virtual указывает, что могут быть различные варианты
функции print() для разных производных классов, и что поиск среди
них подходящей для каждого вызова print() является задачей
компилятора. Тип функции описывается в базовом классе и не может
переписываться в производном классе. Виртуальная функция должна
быть определена для класса, в котором она описана впервые.
Например:
void employee::print()
{
cout << e->name << "\t" << e->department << "\n";
// ...
}
Виртуальная функция может, таким образом, использоваться даже в том
случае, когда нет производных классов от ее класса, и в производном
классе, в котором не нужен специальный вариант виртуальной функции,
ее задавать не обязательно. Просто при выводе класса
соответствующая функция задается в том случае, если она нужна.
Например:
struct manager : employee {
employee* group;
short level;
// ...
void print();
};
void manager::print()
{
employee::print();
cout << "\tуровень" << level << "\n";
// ...
}
Функция print_employee() теперь не нужна, поскольку ее место заняли
функции члены print(), и теперь со списком служащих можно работать
так:
void f(employee* ll)
{
for (; ll; ll=ll->next) ll->print();
}
Каждый служащий будет печататься в соответствии с его типом.
Например:
main()
{
employee e;
e.name = "Дж.Браун";
e.department = 1234;
e.next = 0;
manager m;
m.name = "Дж.Смит";
e.department = 1234;
m.level = 2;
m.next = &e;
f(&m);
}
выдаст
Дж.Смит 1234
уровень 2
Дж.Браун 1234
Заметьте, что это будет работать даже в том случае, если f() была
написана и откомпилирована еще до того, как производный класс
manager был задуман! Очевидно, при реализации этого в каждом
объекте класса employee сохраняется некоторая информация о типе.
Занимаемого для этого пространства (в текущей реализации) как раз
хватает для хранения указателя. Это пространство занимается только
в объектах классов с виртуальными функциями, а не во всех объектах
классов и даже не во всех объектах производных классов. Вы платите
эту пошлину только за те классы, для которых описали виртуальные
функции.
Вызов функции с помощью операции разрешения области видимости ::,
как это делается в manager::print(), гарантирует, что механизм
виртуальных функций применяться не будет. Иначе manager::print()
подвергалось бы бесконечной рекурсии. Применение уточненного имени
имеет еще один эффект, который может оказаться полезным: если
описанная как virtual функция описана еще и как inline (в чем
ничего необычного нет), то там, где в вызове применяется :: может
применяться inline-подстановка. Это дает программисту эффективный
способ справляться с теми важными специальными случаями, когда одна
виртуальная функция вызывает другую для того же объекта. Поскольку
тип объекта был определен при вызове первой виртуальной функции,
обычно его не надо снова динамически определять другом вызове для
того же объекта.
Класс slist не обеспечивает способа заглянуть в список, но только
средства для вставления и удаления элементов. Однако оба класса, и
slist, и slink, описывают класс slist_iterator как друга, поэтому
мы можем описать подходящий итератор. Вот один, написанный в духе
7.3.3 Как Этим Пользоваться
Фактически класс slist в написанном виде бесполезен. В конечном
счете, зачем можно использовать список указателей void*? Штука в
том, чтобы вывести класс из slist и получить список тех объектов,
которые представляют интерес в конкретной программе. Представим
компилятор языка вроде C++. В нем широко будут использоваться
списки имен; имя - это нечто вроде
struct name {
char* string;
// ...
};
В список будут помещаться указатели на имена, а не сами объекты
имена. Это позволяет использовать небольшое информационное поле e
slist'а, и дает возможность имени находиться одновременно более чем
в одном списке. Вот определение класса nlist, который очень просто
выводится из класса slist:
#include "slist.h"
#include "name.h"
struct nlist : slist {
void insert(name* a) { slist::insert(a); }
void append(name* a) { slist::append(a); }
name* get() {}
nlist(name* a) : (a) {}
};
Функции нового класса или наследуются от slist непосредственно, или
ничего не делают кроме преобразования типа. Класс nlist - это
ничто иное, как альтернативный интерфейс класса slist. Так как на
самом деле тип ent есть void*, нет необходимости явно
преобразовывать указатели name*, которые используются в качестве
фактических параметров ( Списки имен можно использовать в классе, который представляет
определение класса:
где is_iterator() и is_friend() являются функциями членами класса
name. Фукнцию find() можно написать так:
Здесь применяется явное преобразование типа, чтобы применить
slist_iterator к nlist. Более хорошее решение, - сделать итератор
для nlist'ов, приведено в #7.3.5. Печатать nlist может, например,
такая функция:
7.3.4 Обработка Ошибок
Есть четыре подхода к проблеме, что же делать, когда во время
выполнения общецелевое средство вроде slist сталкивается с ошибкой
(в C++ нет никаких специальных средств языка для обработке ошибок):
[1] Возвращать недопустимое значение и позволить пользователю его
проверять;
[2] Возвращать дополнительное значение состояния и разрешить
пользователю проверять его;
[3] Вызывать функцию ошибок, заданную как часть класса slist; или
[4] Вызывать функцию ошибок, которую предположительно
предоставляет пользователь.
Для небольшой программы, написанной ее единственным
пользователем, нет фактически никаких особенных причин предпочесть
одно из этих решений другим. Для средства общего назначения
ситуация совершенно иная.
Первый подход, возвращать недопустимое значение, неосуществим.
Нет совершенно никакого способа узнать, что некоторое конкретное
значение будет недопустимым во всех применениях slist.
Второй подход, возвращать значение состояния, можно использовать
в некоторых классах (один из вариантов этого плана применяется в
стандартных потоках ввода/вывода istream и ostream; как -
объясняется в #8.4.2). Здесь, однако, имеется серьезная проблема, вдруг пользователь не позаботится проверить значение состояния,
если средство не слишком часто подводит. Кроме того, средство может
использоваться в сотнях или даже тысячах мест программы. Проверка
значения в каждом месте сильно затруднит чтение программы.
Третьему подходу, предоставлять функцию ошибок, недостает
гибкости. Тот, кто реализует общецелевое средство, не может узнать,
как пользователи захотят, чтобы обрабатывались ошибки. Например,
пользователь может предпочитать сообщения на датском или
венгерском.
Четвертый подход, позволить пользователю задавать функцию ошибок,
имеет некоторую привлекательность при условии, что разработчик
предоставляет класс в виде библиотеки (#4.5), в которой содержатся стандартные функции обработки ошибок. Решения 3 и 4 можно сделать более гибкими (и по сути эквивалентными), задав указатель на функцию, а не саму функцию. Это
позволит разработчику такого средства, как slist, предоставить
функцию ошибок, действующую по умолчанию, и при этом программистам,
которые будут использовать списки, будет легко задать свои
собственные функции ошибок, если нужно, и там, где нужно.
Например:
typedef void (*PFC)(char*); // указатель на тип функция
extern PFC slist_handler;
extern PFC set_slist_handler(PFC);
Функция set_slist_hanlder() позволяет пользователю заменить
стандартную функцию. Общепринятая реализация предоставляет
действующую по умолчанию функцию обработки ошибок, которая сначала
пишет сообщение об ошибке в cerr, после чего завершает программу с
помощью exit():
#include "slist.h"
#include
void default_error(char* s)
{
cerr << s << "\n";
exit(1);
}
Она описывает также указатель на функцию ошибок и, для удобства
записи, функцию для ее установки:
PFC slist_handler = default_error;
PFC set_slist_handler(PFC handler);
{
PFC rr = slist_handler;
slist_handler = handler;
return rr;
}
Обратите внимание, как set_slist_hanlder() возвращает предыдущий
slist_hanlder(). Это делает удобным установку и переустановку
обработчиков ошибок на манер стека. Это может быть в основном
полезным в больших программах, в которых slist может использоваться
в нескольких разных ситуациях, в каждой из которых могут, таким
образом, задаваться свои собственные подпрограммы обработки ошибок.
Например:
{
PFC old = set_slist_handler(my_handler);
// код, в котором в случае ошибок в slist
// будет использоваться мой обработчик my_handler
set_slist_handler(old); // восстановление
}
Чтобы сделать управление более изящным, slist_hanlder мог бы быть
сделан членом класса slist, что позволило бы различным спискам
иметь одновременно разные обработчики.
7.3.5 Обобщенные Классы
Очевидно, можно было бы определить списки других типов
(classdef*, int, char* и т.д.) точно так же, как был определен
класс nlist: простым выводом из класса slist. Процесс определения
таких новых типов утомителен (и потому чреват ошибками), но с
помощью макросов его можно "механизировать". К сожалению, если
пользоваться стандартным C препроцессором (#4.7 и #с.11.1), это тоже может оказаться тягостным. Однако полученными в результате
макросами пользоваться довольно просто.
Вот пример того, как обобщенный (generic) класс slist, названный
gslist, может быть задан как макрос. Сначала для написания такого
рода макросов включаются некоторые инструменты из :
#include "slist.h"
#ifndef GENERICH
#include
#endif
Обратите внимание на использование #ifndef для того, чтобы
гарантировать, что в одной компиляции не будет включен
дважды. GENERICH определен в .
После этого с помощью name2(), макроса из для
конкатенации имен, определяются имена новых обобщенных классов:
#define gslist(type) name2(type,gslist)
#define gslist_iterator(type) name2(type,gslist_iterator)
И, наконец, можно написать классы gslist(тип) и
gslist_iterator(тип):
#define gslistdeclare(type) \
struct gslist(type) : slist { \
int insert(type a) \
{ return slist::insert( ent(a) ); } \
int append(type a) \
{ return slist::append( ent(a) ); } \
type get() { return type( slist::get() ); } \
gslist(type)() { } \
gslist(type)(type a) : (ent(a)) { } \
~gslist(type)() { clear(); } \
}; \
\
struct gslist_iterator(type) : slist_iterator { \
gslist_iterator(type)(gslist(type)& a) \
: ( (slist&)s ) {} \
type operator()() \
{ return type( slist_iterator::operator()() ); } \
}
\ на конце строк указывает , что следующая строка является частью
определяемого макроса.
С помощью этого макроса список указателей на имя, аналогичный
использованному раньше классу nlist, можно определить так:
#include "name.h"
typedef name* Pname;
declare(gslist,Pname); // описать класс gslist(Pname)
gslist(Pname) nl; // описать один gslist(Pname)
Макрос declare (описать) определен в . Он конкатенирует
свои параметры и вызывает макрос с этим именем, в данном случае
gslistdeclare, описанный выше. Параметр имя типа для declare должен
быть простым именем. Используемый метод макроопределения не может
обрабатывать имена типов вроде name*, поэтому применяется typedef.
Использования вывода класса гарантирует, что все частные случаи
обобщенного класса разделяют код. Этот метод можно применять только
для создания классов объектов того же размера или меньше, чем
базовый класс, который используется в макросе. gslist применяется в
7.3.6 Ограниченные Интерфейсы
Класс slist - довольно общего характера. Иногда подобная общность
не требуется или даже нежелательна. Ограниченные виды списков,
такие как стеки и очереди, даже более обычны, чем сам обобщенный
список. Такие структуры данных можно задать, не описав базовый
класс как открытый. Например, очередь целых можно определить так:
#include "slist.h"
class iqueue : slist {
//предполагается sizeof(int)<=sizeof(void*)
public:
void put(int a) { slist::append((void*)a); }
int det() { return int(slist::get()); }
iqueue() {}
};
При таком выводе осуществляются два логически разделенных действия:
понятие списка ограничивается понятием очереди (сводится к нему), и
задается тип int, чтобы свести понятие очереди к типу данных
очередь целых, iqueue. Эти два действия можно выполнять и
раздельно. Здесь первая часть - это список, ограниченный так, что
он может использоваться только как стек:
#include "slist.h"
class stack : slist {
public:
slist::insert;
slist::get;
stack() {}
stack(ent a) : (a) {}
};
который потом используется для создания типа "стек указателей на
символы":
#include "stack.h"
class cp : stack {
public:
void push(char* a) { slist::insert(a); }
char* pop() { return (char*)slist::get(); }
nlist() {}
};
7.4 Добавление к Классу
В предыдущих примерах производный класс ничего не добавлял к
базовому классу. Для производного класса функции определялись
только чтобы обеспечить преобразование типа. Каждый производный
класс просто задавал альтернативный интерфейс к общему множеству
программ. Этот специальный случай важен, но наиболее обычная
причина определения новых классов как производных классов в том, что
кто-то хочет иметь то, что предоставляет базовый класс, плюс еще
чуть-чуть.
Для производного класса можно определить данные и функции
дополнительно к тем, которые наследуются из его базового класса.
Это дает альтернативную стратегию обеспечить средства связанного
списка. Заметьте, когда в тот slist, который определялся выше,
помещается элемент, то создается slink, содержащий два указателя.
На их создание тратится время, а ведь без одного из указателей
можно обойтись, при условии, что нужно только чтобы объект мог
находиться в одном списке. Так что указатель next на следующий
можно поместить в сам объект, вместо того, чтобы помещать его в
отдельный объект slink. Идея состоит в том, чтобы создать класс
olink с единственным полем next, и класс olist, который может
обрабатывать указателями на такие звенья olink. Тогда olist сможет
манипулировать объектами любого класса, производного от olink.
Буква "o" в названиях стоит для того, чтобы напоминать вам, что
объект может находиться одновременно только в одном списке olist:
struct olink {
olink* next;
};
Класс olist очень напоминает класс slist. Отличие состоит в том,
что пользователь класса olist манипулирует объектами класса olink
непосредственно:
class olist {
olink* last;
public:
void insert(olink* p);
void append(olink* p);
olink* get();
// ...
};
Мы можем вывести из класса olink класс name:
class name : public olink {
// ...
};
Теперь легко сделать список, который можно использовать без
накладных расходов времени на размещение или памяти.
Объекты, помещаемы в olist, теряют свой тип. Это означает, что
компилятор знает только то, что они olink'и. Правильный тип можно
восстановить с помощью явного преобразования типа объектов, вынутых
из olist. Например:
void f()
{
olist ll;
name nn;
ll.insert(&nn); // тип &nn потерян
name* pn = (name*)ll.get(); // и восстановлен
}
Другой способ: тип можно восстановить, выведя еще один класс из
olist для обработки преобразования типа:
class olist : public olist {
// ...
name* get() { return (name*)olist::get(); }
};
Имя name может одновременно находиться только в одном olist. Для
имен это может быть и не подходит, но в классах, для которых это
подойдет полностью, недостатка нет. Например, класс фигур shape
использует для поддержки списка всех фигур именно этот метод.
Обратите внимание, что можно было бы определить slist как
производный от olist, объединяя таким образом оба понятия. Однако
использование базовых и производных классов на таком
микроскопическом уровне может очень сильно исказить код.
7.5 Неоднородные Списки
Предыдущие списки были однородными. То есть, в список помещались
только объекты одного типа. Это обеспечивалось аппаратом
производных классов. Списки не обязательно должны быть
однородными. Список, заданный в виде указателей на класс, может
содержать объекты любого класса, производного от этого класса. То
есть, список может быть неоднородным. Вероятно, это единственный
наиболее важный и полезный аспект производных классов, и он весьма
существенно используется в стиле программирования, который
демонстрируется приведенным выше примером. Этот стиль
программирования часто называют объектно-основанным или
объектно-ориентированным. Он опирается на то, что действия над
объектами неоднородных списков выполняются одинаковым образом.
Смысл этих действий зависит от фактического типа объектов,
находящихся в списке (что становится известно только на стадии
выполнения), а не просто от типа элементов списка (который
компилятору известен).
7.6 Законченная Программа
Линию можно построить либо по двум точкам, либо по точке и целому.
В последнем случае создается горизонтальная линия, длину которой
определяет целое. Знак целого указывает, каким концом является
точка: левым или правым. Вот определение:
И вот, наконец, настоящая сервисная функция (утилита). Она кладет
одну фигуру на верх другой, задавая, что south() одной должен быть
сразу над north() другой:
Теперь представим себе, что эта библиотека считается
собственностью некоей компании, которая продает программное
обеспечение, и что они продают вам только заголовочный файл,
содержащий определения фигур, и откомпилированный вариант
определений функций. И у вас все равно остается возможность
определять новые фигуры и использовать для ваших собственных фигур
сервисные функции.
7.6.3 Прикладная Программа
Прикладная программа чрезвычайно проста. Определяется новая
фигура my_shape (на печати она немного похожа на рожицу), а потом
пишется главная программа, которая надевает на нее шляпу. Вначале
описание my_shape:
#include "shape.h"
class myshape : public rectangle {
line* l_eye; // левый глаз
line* r_eye; // правый глаз
line* mouth; // рот
public:
myshape(point, point);
void draw();
void move(int, int);
};
Глаза и рот - отдельные и независимые объекты, которые создает
конструктор my_shape:
myshape::myshape(point a, point b) : (a,b)
{
int ll = neast().x-swest().x+1;
int hh = neast().y-swest().y+1;
l_eye = new line(
point(swest().x+2,swest().y+hh*3/4),2);
r_eye = new line(
point(swest().x+ll-4,swest().y+hh*3/4),2);
mouth = new line(
point(swest().x+2,swest().y+hh/4),ll-4);
}
Объекты глаза и рот порознь рисуются заново функцией
shape_refresh(), и в принципе могут обрабатываться независимо из
объекта my_shape, которому они принадлежат. Это один способ
определять средства для иерархически построенных объектов вроде
my_shape. Другой способ демонстрируется на примере носа. Никакой
нос не определяется, его просто добавляет к картинке функция
draw():
void myshape::draw()
{
rectangle::draw();
put_point(point(
(swest().x+neast().x)/2,(swest().y+neast().y)/2));
}
my_shape передвигается посредством перемещения базового
прямоугольника rectangle и вторичных объектов l_eye, r_eye и mouth
(левого глаза, правого глаза и рта):
void myshape::move()
{
rectangle::move();
l_eye->move(a,b);
r_eye->move(a,b);
mouth->move(a,b);
}
Мы можем, наконец, построить несколько фигур и немного их
подвигать:
main()
{
shape* p1 = new rectangle(point(0,0),point(10,10));
shape* p2 = new line(point(0,15),17);
shape* p3 = new myshape(point(15,10),point(27,18));
shape_refresh();
p3->move(-10,-10);
stack(p2,p3);
stack(p1,p2);
shape_refresh();
return 0;
}
Еще раз обратите внимание, как функции вроде shape_refresh() и
stack() манипулируют объектами типов, определяемых гораздо позже,
чем были написаны (и, может быть, откомпилированы) сами эти
функции.
Результатом работы программы будет:
***********
* *
* *
* *
* *
* *
* *
* *
* *
* *
***********
*****************
*************
* *
* ** ** *
* *
* * *
* *
* ********* *
* *
*************
|
7.7 Свободная Память
Если вы пользовались классом slist, вы могли обнаружить, что ваша
программа тратит на заметное время на размещение и освобождение
объектов класса slink. Класс slink - это превосходный пример
класса, который может значительно выиграть от того, что программист
возьмет под контроль управление свободной памятью. Для этого вида
объектов идеально подходит оптимизирующий метод, который описан в
#5.5.6. Поскольку каждый slink создается с помощью new и уничтожается с помощью delete членами класса slist, другой способ
выделения памяти не представляет никаких проблем.
Если производный класс осуществляет присваивание указателю this,
то конструктор его базового класса будет вызываться только после
этого присваивания, и значение указателя this в конструкторе
базового класса будет тем, которое присвоено конструктором
производного класса. Если базовый класс присваивает указателю this,
то будет присвоено то значение, которое использует конструктор
производного класса. Например:
#include
struct base { base(); };
struct derived : base { derived(); }
base::base()
{
cout << "\tbase 1: this=" << int(this) << "\n";
if (this == 0) this = (base*)27;
cout << "\tbase 2: this=" << int(this) << "\n";
}
derived::derived()
{
cout << "\tderived 1: this=" << int(this) << "\n";
this = (this == 0) ? (derived*)43 : this;
cout << "\tderived 2: this=" << int(this) << "\n";
}
main()
{
cout << "base b;\n";
base b;
cout << "new base b;\n";
new base;
cout << "derived d;\n";
derived d;
cout << "new derived d;\n";
new derived;
cout << "at the end\n";
}
порождает вывод
base b;
base 1: this=2147478307
base 2: this=2147478307
new base;
base 1: this=0
base 2: this=27
derived d;
derived 1: this=2147478306
base 1: this=2147478306
base 2: this=2147478306
derived 1: this=2147478306
new derived;
derived 1: this=0
base 1: this=43
base 2: this=43
derived 1: this=43
at the end
Если деструктор производного класса осуществляет присваивание
указателю this, то будет присвоено то значение, которое встретил
деструктор его базового класса. Когда кто-либо делает в
конструкторе присваивание указателю this, важно, чтобы присваивание
указателю this встречалось на всех путях в конструкторе*1.
7.8 Упражнения
- (*1) Определите
class base {
public:
virtual void iam() { cout << "base\n"; }
};
Выведите из base два класса и для каждого определите iam() ("я
есть"), которая выводит имя класса на печать. Создайте объекты
этих классов и вызовите для них iam(). Присвойте адреса
объектов производных классов указателям base* и вызовите iam()
через эти указатели.
- (*2) Реализуйте примитивы экрана (#7.6.1) подходящим для вашей системы образом.
- (*2) Определите класс triangle (треугольник) и класс circle
(круг).
- (*2) Определите функцию, которая рисует линию, соединяющую две
фигуры, отыскивая две ближайшие "точки соприкосновения" и
соединяя их.
- (*2) Модифицируйте пример с фигурами так, чтобы line была
rectangle и наоборот.
- (*2) Придумайте и реализуйте дважды связанный список, который
можно использовать без итератора.
- (*2) Придумайте и реализуйте дважды связанный список, которым
можно пользоваться только посредством итератора. Итератор
должен иметь действия для движения вперед и назад, действия
для вставления и удаления элементов списка, и способ доступа к
текущему элементу.
- (*2) Постройте обобщенный вариант дважды связанного списка.
- (*4) Сделайте список, в котором вставляются и удаляются сами
объекты (а не просто указатели на объекты). Проделайте это для
класса X, для которого определены X::X(X&), X::~X()
X::operator=(X&).
- (*5) Придумайте и реализуйте библиотеку для написания
моделей, управляемых прерываниями. Подсказка: . Только
это - старая программа, а вы могли бы написать лучше. Должен
быть класс task (- задача). Объект класса task должен мочь
сохранять свое состояние и восстанавливаться в это состояние
(вы можете определить task::save() и task::restore()), чтобы
он мог действовать как сопрограмма. Отдельные задачи можно
определять как объекты классов, производных от класса task.
Программа, которую должна исполнять задача, модет задаваться
как виртуальная функция. Должна быть возможность передавать
новой задаче ее параметры как параметры ее конструктора(ов).
Там должен быть планировщик, реализующий концепцию
виртуального времени. Обеспечьте функцию задержки
task::delay(), которая "тратит" виртуальное время. Будет ли
планировщик отдельным или частью класса task - это один из
основных вопросов, которые надо решить при проектировании.
Задача должна передавать данные. Для этого разработайте класс
queue (очередь). Придумайте способ, чтобы задача ожидала ввода
из нескольких очередей. Ошибки в ходе выполнения обрабатывайте
единообразно. Как бы вы отлаживали программы, написанные с
помощью такой библиотеки?
*1 К сожалению, об этом присваивании легко забыть. Например, в
первом издании этой книги (английском - перев.) вторая строка
конструктор derived::derived() читалась так:
if (this == 0) this = (derived*)43;
И следовательно, для d конструктор базового класса base::base() не
вызывался. Программа была допустимой и корректно выполнялась, но
очевидно делала не то, что подразумевал автор. (прим. автора)
[Назад]
[Содержание]
[Вперед]