Страница:
/*
обнаружение ошибки просто, восстановление - трудная задача
*/
{
try {
T* p1 = c1.get();
T* p2 = c2[3];
// ...
}
catch(container::Bad_operation& bad) {
// Приехали!
// А что теперь делать?
}
}
или другой пример:
void user3(container& c1, container& c2)
/*
обнаружение ошибки непросто,
а восстановление по прежнему трудная задача
*/
{
slist* sl = ptr_cast(slist_container,&c1);
vector* v = ptr_cast(vector_container, &c2);
if (sl && v) {
T* p1 = c1.get();
T* p2 = c2[3];
// ...
}
else {
// Приехали!
// А что теперь делать?
}
}
Оба способа обнаружения ошибки, показанные на этих примерах,
приводят к программе с "раздутым" кодом и низкой скоростью
выполнения. Поэтому обычно просто игнорируют возможные ошибки
в надежде, что пользователь на них не натолкнется. Но задача от этого
не упрощается, ведь полное тестирование затруднительно и требует
многих усилий .
Поэтому, если целью является программа с хорошими характеристиками,
или требуются высокие гарантии корректности программы, или, вообще,
есть хорошая альтернатива, лучше не использовать обширные интерфейсы.
Кроме того, использование обширного интерфейса нарушает
взаимнооднозначное соответствие между классами и понятиями, и тогда
начинают вводить новые производные классы просто для удобства
реализации.
Мы перечислили виды классов, из которых можно создать библиотеки,
нацеленные на проектирование и повторное использование прикладных
программ. Они предоставляют определенные "строительные блоки" и
объясняют как из них строить. Разработчик прикладного обеспечения создает
каркас, в который должны вписаться универсальные строительные блоки. Задача
проектирования прикладных программ может иметь иное, более обязывающее
решение: написать программу, которая сама будет создавать общий каркас
области приложения. Разработчик прикладного обеспечения
в качестве строительных блоков будет встраивать в этот каркас
прикладные программы. Классы, которые образуют каркас области
приложения, имеют настолько обширный интерфейс, что их трудно
назвать типами в обычном смысле слова. Они приближаются к тому
пределу, когда становятся чисто прикладными классами, но при этом
в них фактически есть только описания, а все действия задаются
функциями, написанными прикладными программистами.
Для примера рассмотрим фильтр, т.е. программу, которая может
выполнять следующие действия: читать входной поток, производить
над ним некоторые операции, выдавать выходной поток и определять
конечный результат. Примитивный каркас для фильтра будет состоять
из определения множества операций, которые должен реализовать
прикладной программист:
class filter {
public:
class Retry {
public:
virtual const char* message() { return 0; }
};
virtual void start() { }
virtual int retry() { return 2; }
virtual int read() = 0;
virtual void write() { }
virtual void compute() { }
virtual int result() = 0;
};
Нужные для производных классов функции описаны как чистые виртуальные,
остальные функции просто пустые. Каркас содержит основной цикл
обработки и зачаточные средства обработки ошибок:
int main_loop(filter* p)
{
for (;;) {
try {
p->start();
while (p->read()) {
p->compute();
p->write();
}
return p->result();
}
catch (filter::Retry& m) {
cout << m.message() << '\n';
int i = p->retry();
if (i) return i;
}
catch (...) {
cout << "Fatal filter error\n";
return 1;
}
}
}
Теперь прикладную программу можно написать так:
class myfilter : public filter {
istream& is;
ostream& os;
char c;
int nchar;
public:
int read() { is.get(c); return is.good(); }
void compute() { nchar++; };
int result()
{ os << nchar
<< "characters read\n";
return 0;
}
myfilter(istream& ii, ostream& oo)
: is(ii), os(oo), nchar(0) { }
};
и вызывать ее следующим образом:
int main()
{
myfilter f(cin,cout);
return main_loop(&f);
}
Настоящий каркас, чтобы рассчитывать на применение в реальных задачах,
должен создавать более развитые структуры и предоставлять больше
полезных функций, чем в нашем простом примере. Как правило, каркас
образует дерево узловых классов. Прикладной программист поставляет
только классы, служащие листьями в этом многоуровневом дереве,
благодаря чему достигается общность между различными прикладными
программами и упрощается повторное использование полезных функций,
предоставляемых каркасом. Созданию каркаса могут способствовать
библиотеки, в которых определяются некоторые полезные классы, например,
такие как scrollbar ($$12.2.5) и dialog_box ($$13.4). После определения
своих прикладных классов программист может использовать эти классы.
Про один из самых важных видов классов обычно забывают - это "скромные"
интерфейсные классы. Такой класс не выполняет какой-то большой
работы, ведь иначе, его не называли бы интерфейсным. Задача
интерфейсном класса приспособить некоторую полезную функцию к
определенному контексту. Достоинство интерфейсных классов в том,
что они позволяют совместно использовать полезную функцию, не загоняя
ее в жесткие рамки. Действительно, невозможно рассчитывать, что функция
сможет сама по себе одинаково хорошо удовлетворить самые разные запросы.
Интерфейсный класс в чистом виде даже не требует генерации кода.
Вспомним описание шаблона типа Splist из $$8.3.2:
template<class T>
class Splist : private Slist<void*> {
public:
void insert(T* p) { Slist<void*>::insert(p); }
void append(T* p) { Slist<void*>::append(p); }
T* get() { return (T*) Slist<void*>::get(); }
};
Класс Splist преобразует список ненадежных обобщенных указателей
типа void* в более удобное семейство надежных классов, представляющих
списки. Чтобы применение интерфейсных классов не было слишком накладно,
нужно использовать функции-подстановки. В примерах, подобных
приведенному, где задача функций-подстановок только подогнать
тип, накладные расходы в памяти и скорости выполнения программы
не возникают.
Естественно, можно считать интерфейсным абстрактный
базовый класс, который представляет абстрактный тип, реализуемый
конкретными типами ($$13.3), также как и управляющие классы
из раздела 13.9. Но здесь мы рассматриваем классы, у которых нет
иных назначений - только задача адаптации интерфейса.
Рассмотрим задачу слияния двух иерархий классов с помощью
множественного наследования. Как быть в случае коллизии
имен, т.е. ситуации, когда в двух классах используются виртуальные
функции с одним именем, производящие совершенно разные операции?
Пусть есть видеоигра под названием "Дикий запад", в которой диалог
с пользователем организуется с помощью окна общего вида (класс
Window):
class Window {
// ...
virtual void draw();
};
class Cowboy {
// ...
virtual void draw();
};
class CowboyWindow : public Cowboy, public Window {
// ...
};
В этой игре класс CowboyWindow представляет движение ковбоя на экране
и управляет взаимодействием игрока с ковбоем. Очевидно, появится
много полезных функций, определенных в классе Window и
Cowboy, поэтому предпочтительнее использовать множественное наследование,
чем описывать Window или Cowboy как члены. Хотелось бы передавать
этим функциям в качестве параметра объект типа CowboyWindow, не требуя
от программиста указания каких-то спецификаций объекта. Здесь
как раз и возникает вопрос, какую функции выбрать для CowboyWindow:
Cowboy::draw() или Window::draw().
В классе CowboyWindow может быть только одна функция с именем
draw(), но поскольку полезная функция работает с объектами Cowboy
или Window и ничего не знает о CowboyWindow, в классе CowboyWindow
должны подавляться (переопределяться) и функция Cowboy::draw(), и
функция Window_draw(). Подавлять обе функции с помощью одной -
draw() неправильно, поскольку, хотя используется одно имя, все же
все функции draw() различны и не могут переопределяться одной.
Наконец, желательно, чтобы в классе CowboyWindow наследуемые
функции Cowboy::draw() и Window::draw() имели различные однозначно
заданные имена.
Для решения этой задачи нужно ввести дополнительные классы для
Cowboy и Window. Вводится два новых имени
для функций draw() и гарантируется, что их вызов
в классах Cowboy и Window приведет к вызову функций с новыми именами:
class CCowboy : public Cowboy {
virtual int cow_draw(int) = 0;
void draw() { cow_draw(i); } // переопределение Cowboy::draw
};
class WWindow : public Window {
virtual int win_draw() = 0;
void draw() { win_draw(); } // переопределение Window::draw
};
Теперь с помощью интерфейсных классов CCowboy и WWindow можно
определить класс CowboyWindow и сделать требуемые переопределения
функций cow_draw() и win_draw:
class CowboyWindow : public CCowboy, public WWindow {
// ...
void cow_draw();
void win_draw();
};
Отметим, что в действительности трудность возникла лишь потому, что
у обеих функций draw() одинаковый тип параметров. Если бы типы
параметров различались, то обычные правила разрешения неоднозначности
при перегрузке гарантировали бы, что трудностей не возникнет, несмотря на
наличие различных функций с одним именем.
Для каждого случая использования интерфейсного класса можно
предложить такое расширение языка, чтобы требуемая адаптация
проходила более эффективно или задавалась более элегантным способом.
Но такие случаи являются достаточно редкими, и нет смысла чрезмерно
перегружать язык, предоставляя специальные средства для каждого
отдельного случая. В частности, случай коллизии имен при слиянии иерархий
классов довольно редки, особенно если сравнивать с
тем, насколько часто программист создает классы. Такие случаи
могут возникать при слиянии иерархий классов из разных
областей (как в нашем примере: игры и операционные системы).
Слияние таких разнородных структур классов всегда непростая задача,
и разрешение коллизии имен является в ней далеко не самой трудной
частью. Здесь возникают проблемы из-за разных стратегий обработки
ошибок, инициализации, управления памятью. Пример, связанный
с коллизией имен, был приведен потому, что предложенное решение:
введение интерфейсных классов с функциями-переходниками, - имеет
много других применений. Например, с их помощью можно менять
не только имена, но и типы параметров и возвращаемых значений,
вставлять определенные динамические проверки и т.д.
Функции-переходники CCowboy::draw() и WWindow_draw являются
виртуальными, и простая оптимизация с помощью подстановки невозможна.
Однако, есть возможность, что транслятор распознает такие функции
и удалит их из цепочки вызовов.
Интерфейсные функции служат для приспособления интерфейса к
запросам пользователя. Благодаря им в интерфейсе собираются операции,
разбросанные по всей программе. Обратимся к классу vector из $$1.4.
Для таких векторов, как и для массивов, индекс
отсчитывается от нуля. Если пользователь хочет работать с
диапазоном индексов, отличным от диапазона 0..size-1, нужно сделать
соответствующие приспособления, например, такие:
void f()
{
vector v(10); // диапазон [0:9]
// как будто v в диапазоне [1:10]:
for (int i = 1; i<=10; i++) {
v[i-1] = ... // не забыть пересчитать индекс
}
// ...
}
Лучшее решение дает класс vec c произвольными границами индекса:
class vec : public vector {
int lb;
public:
vec(int low, int high)
: vector(high-low+1) { lb=low; }
int& operator[](int i)
{ return vector::operator[](i-lb); }
int low() { return lb; }
int high() { return lb+size() - 1; }
};
Класс vec можно использовать без дополнительных операций, необходимых
в первом примере:
void g()
{
vec v(1,10); // диапазон [1:10]
for (int i = 1; i<=10; i++) {
v[i] = ...
}
// ...
}
Очевидно, вариант с классом vec нагляднее и безопаснее.
Интерфейсные классы имеют и другие важные области применения,
например, интерфейс между программами на С++ и программами на другом
языке ($$12.1.4) или интерфейс с особыми библиотеками С++.
Концепция абстрактного класса дает эффективное средство для разделения
интерфейса и его реализации. Мы применяли эту концепцию и получали
постоянную связь между интерфейсом, заданным абстрактным типом,
и реализацией, представленной конкретным типом. Так, невозможно
переключить абстрактный итератор с одного класса-источника на
другой, например, если исчерпано множество (класс set), невозможно
перейти на потоки.
Далее, пока мы работаем с объектами абстрактного типа с помощью
указателей или ссылок, теряются все преимущества виртуальных
функций. Программа пользователя начинает зависеть от конкретных классов
реализации. Действительно, не зная размера объекта, даже при
абстрактном типе нельзя разместить объект в стеке, передать как параметр
по значению или разместить как статический. Если работа с объектами
организована через указатели или ссылки, то задача распределения
памяти перекладывается на пользователя ($$13.10).
Существует и другое ограничение, связанное с использованием абстрактных
типов. Объект такого класса всегда имеет определенный размер,
но классы, отражающие реальное понятие, могут требовать память
разных размеров.
Есть распространенный прием преодоления этих трудностей, а именно,
разбить отдельный объект на две части: управляющую, которая определяет
интерфейс объекта, и содержательную, в которой находятся все
или большая часть атрибутов объекта. Связь между двумя частями
реализуется с помощью указателя в управляющей части на содержательную
часть. Обычно в управляющей части кроме указателя есть
и другие данные, но их немного. Суть в том, что состав управляющей
части не меняется при изменении содержательной части, и она
настолько мала, что можно свободно работать с самими объектами,
а не с указателями или ссылками на них.
управляющая часть содержательная часть
Простым примером управляющего класса может служить класс string из
$$7.6. В нем содержится интерфейс, контроль доступа и управление
памятью для содержательной части. В этом примере управляющая и
содержательная части представлены конкретными типами, но чаще
содержательная часть представляется абстрактным классом.
Теперь вернемся к абстрактному типу set из $$13.3. Как можно
определить управляющий класс для этого типа, и какие это даст плюсы
и минусы? Для данного класса set можно определить управляющий
класс просто перегрузкой операции ->:
class set_handle {
set* rep;
public:
set* operator->() { return rep; }
set_handler(set* pp) : rep(pp) { }
};
Это не слишком влияет на работу с множествами, просто передаются
объекты типа set_handle вместо объектов типа set& или set*,
например:
void my(set_handle s)
{
for (T* p = s->first(); p; p = s->next())
{
// ...
}
// ...
}
void your(set_handle s)
{
for (T* p = s->first(); p; p = s->next())
{
// ...
}
// ...
}
void user()
{
set_handle sl(new slist_set);
set_handle v(new vector_set v(100));
my(sl);
your(v);
my(v);
your(sl);
}
Если классы set и set_handle разрабатывались совместно,легко
реализовать подсчет числа создаваемых множеств:
class set {
friend class set_handle;
protected:
int handle_count;
public:
virtual void insert(T*) = 0;
virtual void remove(T*) = 0;
virtual int is_member(T*) = 0;
virtual T* first() = 0;
virtual T* next() = 0;
set() : handle_count(0) { }
};
Чтобы подсчитать число объектов данного типа set, в управляющем
классе нужно увеличивать или уменьшать значение счетчика
set_handle:
class set_handle {
set* rep;
public:
set* operator->() { return rep; }
set_handle(set* pp)
: rep(pp) { pp->handle_count++; }
set_handle(const set_handle& r)
: rep(r.rep) { rep->handle_count++; }
set_handle& operator=(const set_handle& r)
{
rep->handle_count++;
if (--rep->handle_count == 0) delete rep;
rep = r.rep;
return *this;
}
~set_handle()
{ if (--rep->handle_count == 0) delete rep; }
};
Если все обращения к классу set обязательно идут через
set_handle, пользователь может не беспокоиться о распределении
памяти под объекты типа set.
На практике иногда приходится извлекать указатель на содержательную
часть из управляющего класса и пользоваться непосредственно им.
Можно, например, передать такой указатель функции, которая ничего
не знает об управляющем классе. Если функция не уничтожает объект,
на который она получила указатель, и если она не сохраняет указатель
для дальнейшего использования после возврата, никаких ошибок быть
не должно. Может оказаться полезным переключение управляющего класса
на другую содержательную часть:
class set_handle {
set* rep;
public:
// ...
set* get_rep() { return rep; }
void bind(set* pp)
{
pp->handle_count++;
if (--rep->handle_count == 0) delete rep;
rep = pp;
}
};
Создание новых производных от set_handle классов обычно не имеет
особого смысла, поскольку это - конкретный тип без виртуальных
функций. Другое дело - построить управляющий класс для семейства
классов, определяемых одним базовым. Полезным приемом будет
создание производных от такого управляющего класса. Этот прием можно
применять как для узловых классов, так и для абстрактных типов.
Естественно задавать управляющий класс как шаблон типа:
template<class T> class handle {
T* rep;
public:
T* operator->() { return rep; }
// ...
};
Но при таком подходе требуется взаимодействие между
управляющим и "управляемым" классами. Если управляющий и управляемые
классы разрабатываются совместно, например, в процессе создания
библиотеки, то это может быть допустимо. Однако, существуют и другие
решения ($$13.10).
За счет перегрузки операции -> управляющий класс получает
возможность контроля и выполнения каких-то операций при каждом
обращении к объекту. Например, можно вести подсчет частоты
использования объектов через управляющий класс:
template<class T>
class Xhandle {
T* rep;
int count;
public:
T* operator->() { count++; return rep; }
// ...
};
Нужна более сложная техника, если требуется выполнять операции как
перед, так и после обращения к объекту. Например, может потребоваться
множество с блокировкой при выполнении операций добавления к
множеству и удаления из него. Здесь, по сути, в управляющем классе
приходится дублировать интерфейс с объектами содержательной части:
class set_controller {
set* rep;
// ...
public:
lock();
unlock();
virtual void insert(T* p)
{ lock(); rep->insert(p); unlock(); }
virtual void remove(T* p)
{ lock(); rep->remove(p); unlock(); }
virtual int is_member(T* p)
{ return rep->is_member(p); }
virtual T* first() { return rep->first(); }
virtual T* next() { return rep->next(); }
// ...
};
Писать функции-переходники для всего интерфейса утомительно (а значит
могут появляться ошибки), но не трудно и это не ухудшает
характеристик программы.
Заметим, что не все функции из set следует блокировать. Как
показывает опыт автора, типичный случай, когда операции до и после
обращения к объекту надо выполнять не для всех, а только для некоторых
функций-членов. Блокировка всех операций, как это делается в
мониторах некоторых операционных систем, является избыточной и может
существенно ухудшить параллельный режим выполнения.
Переопределив все функции интерфейса в управляющем классе, мы
получили по сравнению с приемом перегрузки операции ->, то
преимущество, что теперь можно строить производные
от set_controller классы. К сожалению, мы можем потерять и некоторые
достоинства управляющего класса, если к производным классам будут
добавляться члены, представляющие данные. Можно сказать, что
программный объем, который разделяется между управляемыми классами
уменьшается по мере роста программного объема управляющего класса.
При проектировании библиотеки или просто программы с большим временем
счета один из ключевых вопросов связан с управлением памятью.
В общем случае создатель библиотеки не знает, в каком окружении она
будет работать. Будет ли там ресурс памяти настолько критичен, что ее
нехватка станет серьезной проблемой, или же серьезной помехой станут
накладные расходы, связанные с управлением памятью?
Один из основных вопросов управления памятью можно сформулировать
так: если функция f() передает или возвращает указатель на объект, то
кто должен уничтожать этот объект? Необходимо ответить и на связанный
с ним вопрос: в какой момент объект может быть уничтожен? Ответы на эти
вопросы особенно важны для создателей и пользователей таких контейнеров,
как списки, массивы и ассоциативные массивы. С точки зрения
создателя библиотеки идеальными будут ответы: "Система" и "В тот момент,
когда объект больше никто не использует". Когда система уничтожает
объект, обычно говорят, что она занимается сборкой мусора, а та часть
системы, которая определяет, что объект больше никем не используется,
и уничтожает его, называется сборщиком мусора.
К сожалению, использование сборщика мусора может повлечь за собой
накладные расходы на время счета и память, прерывания полезных
функций, определенную аппаратную поддержку, трудности связывания
частей программы на разных языках или просто усложнение системы.
Многие пользователи не могут позволить себе этого.Ь
Ь Говорят, что программисты на Лиспе знают, насколько важно управление
памятью, и поэтому не могут отдать его пользователю. Программисты
на С тоже знают, насколько важно управление памятью, и поэтому не
могут оставить его системе.
Поэтому в большинстве программ на С++ не приходится рассчитывать
на сборщик мусора и нужно предложить свою стратегию размещения
объектов в свободной памяти, не обращаясь к системе. Но реализации
С++ со сборщиком мусора все-таки существуют.
Рассмотрим самую простую схему управления памятью для программ
на С++. Для этого заменим operator new() на тривиальную функцию
размещения, а operator delete() - на пустую функцию:
inline size_t align(size_t s)
/*
Даже в простой функции размещения нужно
выравнивание памяти, чтобы на объект
можно было настроить указатель
произвольного типа
*/
{
union Word { void* p; long double d; long l; }
int x = s + sizeof(Word) - 1;
x -= x%sizeof(Word);
return x;
}
static void* freep; // настроим start на свободную память
void* operator new(size_t s) // простая линейная функция размещения
{
void* p = freep;
s = align(s);
freep += s;
return p;
}
void operator delete(void*) { } // пусто
Если память бесконечна, то наше решение дает сборщик мусора без
всяких сложностей и накладных расходов. Такой подход не применим
для библиотек, когда заранее неизвестно, каким образом будет
использоваться память, и когда программа, пользующаяся библиотекой,
будет иметь большое время счета. Такой способ выделения памяти
идеально подходит для программ, которым требуется ограниченный объем
памяти или объем, пропорциональный размеру входного потока данных.
Сборку мусора можно рассматривать как моделирование бесконечной
памяти на памяти ограниченного размера. Помня об этом, можно
ответить на типичный вопрос: должен ли сборщик мусора вызывать
деструктор для тех объектов, память которых он использует? Правильный
ответ - нет, поскольку, если размещенный в свободной памяти объект
не был удален, то он не будет и уничтожен. Исходя из этого, операцию
delete можно рассматривать как запрос на вызов деструктора (и еще это
- сообщение системе, что память объекта можно использовать). Но как
быть, если действительно требуется уничтожить размещенный в свободной
памяти объект, который не был удален? Заметим, что для
статических и автоматических объектов такой вопрос не встает, -
деструкторы для них неявно вызываются всегда. Далее, уничтожение
объекта "во время сборки мусора" по сути является
операцией с непредсказуемым результатом. Она может совершиться
в любое время между последним использованием объекта и "концом
программы"Ь, а значит, в каком состоянии будет программа в этот момент
неизвестно.
Ь Здесь использованы кавычки, потому что трудно точно определить,
что такое конец программы. (прим. перев.)
Трудно правильно запрограммировать такие операции и они не так полезны,
как кажется.
Задачу уничтожения объектов, если время этой операции точно не задано,
можно решить с помощью программы обслуживания заявок на уничтожение. Назовем
ее сервером заявок. Если объект необходимо уничтожить в конце программы,
то надо записать в глобальный ассоциативный массив его адрес и
указатель на функцию "очистки". Если объект удален явной операцией,
заявка аннулируется. При уничтожении самого сервера (в конце
программы) вызываются функции очистки для всех оставшихся заявок.
Это решение подходит и для сборки мусора, поскольку мы рассматриваем
ее как моделирование бесконечной памяти. Для сборщика мусора нужно
выбрать одно из двух решений: либо удалять объект, когда единственной
оставшейся ссылкой на него будет ссылка, находящаяся в массиве самого
сервера, либо (стандартное решение) не удалять объект до конца
программы, поскольку все-таки ссылка на него есть.
Сервер заявок можно реализовать как ассоциативный массив ($$8.8):
class Register {
Map<void*, void (*) (void*)> m;
public:
insert(void* po, void(*pf)()) { m[po]=pf; }
remove(void* po) { m.remove(po); }
};
Register cleanup_register;
Класс, постоянно обращающийся к серверу, может выглядеть так:
class X {
// ...
static void cleanup(void*);
public:
X()
{
cleanup_register.insert(this,&cleanup);
// ...
}
~X() { cleanup(this); }
// ...
};
void X::cleanup(void* pv)
{
X* px = (X*)pv;
cleanup_register.remove(pv);
// очистка
}
Чтобы в классе Register не иметь дела с типами, мы использовали
статическую функцию-член с указателем типа void*.
Допустим, что у нас нет бесконечной памяти и сборщика мусора. На какие
средства управления памятью может рассчитывать создатель
контейнера, например, класса Vector? Для случая таких простых элементов,
как int, очевидно, надо просто копировать их в контейнер. Столь же
очевидно, что для других типов, таких, как абстрактный класс Shape,
в контейнере следует хранить указатель. Создатель библиотеки
должен предусмотреть оба варианта. Приведем набросок очевидного
решения:
template<class T> Vector {
T* p;
int sz;
public:
Vector(int s) { p = new T[sz=s]; }
// ...
обнаружение ошибки просто, восстановление - трудная задача
*/
{
try {
T* p1 = c1.get();
T* p2 = c2[3];
// ...
}
catch(container::Bad_operation& bad) {
// Приехали!
// А что теперь делать?
}
}
или другой пример:
void user3(container& c1, container& c2)
/*
обнаружение ошибки непросто,
а восстановление по прежнему трудная задача
*/
{
slist* sl = ptr_cast(slist_container,&c1);
vector* v = ptr_cast(vector_container, &c2);
if (sl && v) {
T* p1 = c1.get();
T* p2 = c2[3];
// ...
}
else {
// Приехали!
// А что теперь делать?
}
}
Оба способа обнаружения ошибки, показанные на этих примерах,
приводят к программе с "раздутым" кодом и низкой скоростью
выполнения. Поэтому обычно просто игнорируют возможные ошибки
в надежде, что пользователь на них не натолкнется. Но задача от этого
не упрощается, ведь полное тестирование затруднительно и требует
многих усилий .
Поэтому, если целью является программа с хорошими характеристиками,
или требуются высокие гарантии корректности программы, или, вообще,
есть хорошая альтернатива, лучше не использовать обширные интерфейсы.
Кроме того, использование обширного интерфейса нарушает
взаимнооднозначное соответствие между классами и понятиями, и тогда
начинают вводить новые производные классы просто для удобства
реализации.
Мы перечислили виды классов, из которых можно создать библиотеки,
нацеленные на проектирование и повторное использование прикладных
программ. Они предоставляют определенные "строительные блоки" и
объясняют как из них строить. Разработчик прикладного обеспечения создает
каркас, в который должны вписаться универсальные строительные блоки. Задача
проектирования прикладных программ может иметь иное, более обязывающее
решение: написать программу, которая сама будет создавать общий каркас
области приложения. Разработчик прикладного обеспечения
в качестве строительных блоков будет встраивать в этот каркас
прикладные программы. Классы, которые образуют каркас области
приложения, имеют настолько обширный интерфейс, что их трудно
назвать типами в обычном смысле слова. Они приближаются к тому
пределу, когда становятся чисто прикладными классами, но при этом
в них фактически есть только описания, а все действия задаются
функциями, написанными прикладными программистами.
Для примера рассмотрим фильтр, т.е. программу, которая может
выполнять следующие действия: читать входной поток, производить
над ним некоторые операции, выдавать выходной поток и определять
конечный результат. Примитивный каркас для фильтра будет состоять
из определения множества операций, которые должен реализовать
прикладной программист:
class filter {
public:
class Retry {
public:
virtual const char* message() { return 0; }
};
virtual void start() { }
virtual int retry() { return 2; }
virtual int read() = 0;
virtual void write() { }
virtual void compute() { }
virtual int result() = 0;
};
Нужные для производных классов функции описаны как чистые виртуальные,
остальные функции просто пустые. Каркас содержит основной цикл
обработки и зачаточные средства обработки ошибок:
int main_loop(filter* p)
{
for (;;) {
try {
p->start();
while (p->read()) {
p->compute();
p->write();
}
return p->result();
}
catch (filter::Retry& m) {
cout << m.message() << '\n';
int i = p->retry();
if (i) return i;
}
catch (...) {
cout << "Fatal filter error\n";
return 1;
}
}
}
Теперь прикладную программу можно написать так:
class myfilter : public filter {
istream& is;
ostream& os;
char c;
int nchar;
public:
int read() { is.get(c); return is.good(); }
void compute() { nchar++; };
int result()
{ os << nchar
<< "characters read\n";
return 0;
}
myfilter(istream& ii, ostream& oo)
: is(ii), os(oo), nchar(0) { }
};
и вызывать ее следующим образом:
int main()
{
myfilter f(cin,cout);
return main_loop(&f);
}
Настоящий каркас, чтобы рассчитывать на применение в реальных задачах,
должен создавать более развитые структуры и предоставлять больше
полезных функций, чем в нашем простом примере. Как правило, каркас
образует дерево узловых классов. Прикладной программист поставляет
только классы, служащие листьями в этом многоуровневом дереве,
благодаря чему достигается общность между различными прикладными
программами и упрощается повторное использование полезных функций,
предоставляемых каркасом. Созданию каркаса могут способствовать
библиотеки, в которых определяются некоторые полезные классы, например,
такие как scrollbar ($$12.2.5) и dialog_box ($$13.4). После определения
своих прикладных классов программист может использовать эти классы.
Про один из самых важных видов классов обычно забывают - это "скромные"
интерфейсные классы. Такой класс не выполняет какой-то большой
работы, ведь иначе, его не называли бы интерфейсным. Задача
интерфейсном класса приспособить некоторую полезную функцию к
определенному контексту. Достоинство интерфейсных классов в том,
что они позволяют совместно использовать полезную функцию, не загоняя
ее в жесткие рамки. Действительно, невозможно рассчитывать, что функция
сможет сама по себе одинаково хорошо удовлетворить самые разные запросы.
Интерфейсный класс в чистом виде даже не требует генерации кода.
Вспомним описание шаблона типа Splist из $$8.3.2:
template<class T>
class Splist : private Slist<void*> {
public:
void insert(T* p) { Slist<void*>::insert(p); }
void append(T* p) { Slist<void*>::append(p); }
T* get() { return (T*) Slist<void*>::get(); }
};
Класс Splist преобразует список ненадежных обобщенных указателей
типа void* в более удобное семейство надежных классов, представляющих
списки. Чтобы применение интерфейсных классов не было слишком накладно,
нужно использовать функции-подстановки. В примерах, подобных
приведенному, где задача функций-подстановок только подогнать
тип, накладные расходы в памяти и скорости выполнения программы
не возникают.
Естественно, можно считать интерфейсным абстрактный
базовый класс, который представляет абстрактный тип, реализуемый
конкретными типами ($$13.3), также как и управляющие классы
из раздела 13.9. Но здесь мы рассматриваем классы, у которых нет
иных назначений - только задача адаптации интерфейса.
Рассмотрим задачу слияния двух иерархий классов с помощью
множественного наследования. Как быть в случае коллизии
имен, т.е. ситуации, когда в двух классах используются виртуальные
функции с одним именем, производящие совершенно разные операции?
Пусть есть видеоигра под названием "Дикий запад", в которой диалог
с пользователем организуется с помощью окна общего вида (класс
Window):
class Window {
// ...
virtual void draw();
};
class Cowboy {
// ...
virtual void draw();
};
class CowboyWindow : public Cowboy, public Window {
// ...
};
В этой игре класс CowboyWindow представляет движение ковбоя на экране
и управляет взаимодействием игрока с ковбоем. Очевидно, появится
много полезных функций, определенных в классе Window и
Cowboy, поэтому предпочтительнее использовать множественное наследование,
чем описывать Window или Cowboy как члены. Хотелось бы передавать
этим функциям в качестве параметра объект типа CowboyWindow, не требуя
от программиста указания каких-то спецификаций объекта. Здесь
как раз и возникает вопрос, какую функции выбрать для CowboyWindow:
Cowboy::draw() или Window::draw().
В классе CowboyWindow может быть только одна функция с именем
draw(), но поскольку полезная функция работает с объектами Cowboy
или Window и ничего не знает о CowboyWindow, в классе CowboyWindow
должны подавляться (переопределяться) и функция Cowboy::draw(), и
функция Window_draw(). Подавлять обе функции с помощью одной -
draw() неправильно, поскольку, хотя используется одно имя, все же
все функции draw() различны и не могут переопределяться одной.
Наконец, желательно, чтобы в классе CowboyWindow наследуемые
функции Cowboy::draw() и Window::draw() имели различные однозначно
заданные имена.
Для решения этой задачи нужно ввести дополнительные классы для
Cowboy и Window. Вводится два новых имени
для функций draw() и гарантируется, что их вызов
в классах Cowboy и Window приведет к вызову функций с новыми именами:
class CCowboy : public Cowboy {
virtual int cow_draw(int) = 0;
void draw() { cow_draw(i); } // переопределение Cowboy::draw
};
class WWindow : public Window {
virtual int win_draw() = 0;
void draw() { win_draw(); } // переопределение Window::draw
};
Теперь с помощью интерфейсных классов CCowboy и WWindow можно
определить класс CowboyWindow и сделать требуемые переопределения
функций cow_draw() и win_draw:
class CowboyWindow : public CCowboy, public WWindow {
// ...
void cow_draw();
void win_draw();
};
Отметим, что в действительности трудность возникла лишь потому, что
у обеих функций draw() одинаковый тип параметров. Если бы типы
параметров различались, то обычные правила разрешения неоднозначности
при перегрузке гарантировали бы, что трудностей не возникнет, несмотря на
наличие различных функций с одним именем.
Для каждого случая использования интерфейсного класса можно
предложить такое расширение языка, чтобы требуемая адаптация
проходила более эффективно или задавалась более элегантным способом.
Но такие случаи являются достаточно редкими, и нет смысла чрезмерно
перегружать язык, предоставляя специальные средства для каждого
отдельного случая. В частности, случай коллизии имен при слиянии иерархий
классов довольно редки, особенно если сравнивать с
тем, насколько часто программист создает классы. Такие случаи
могут возникать при слиянии иерархий классов из разных
областей (как в нашем примере: игры и операционные системы).
Слияние таких разнородных структур классов всегда непростая задача,
и разрешение коллизии имен является в ней далеко не самой трудной
частью. Здесь возникают проблемы из-за разных стратегий обработки
ошибок, инициализации, управления памятью. Пример, связанный
с коллизией имен, был приведен потому, что предложенное решение:
введение интерфейсных классов с функциями-переходниками, - имеет
много других применений. Например, с их помощью можно менять
не только имена, но и типы параметров и возвращаемых значений,
вставлять определенные динамические проверки и т.д.
Функции-переходники CCowboy::draw() и WWindow_draw являются
виртуальными, и простая оптимизация с помощью подстановки невозможна.
Однако, есть возможность, что транслятор распознает такие функции
и удалит их из цепочки вызовов.
Интерфейсные функции служат для приспособления интерфейса к
запросам пользователя. Благодаря им в интерфейсе собираются операции,
разбросанные по всей программе. Обратимся к классу vector из $$1.4.
Для таких векторов, как и для массивов, индекс
отсчитывается от нуля. Если пользователь хочет работать с
диапазоном индексов, отличным от диапазона 0..size-1, нужно сделать
соответствующие приспособления, например, такие:
void f()
{
vector v(10); // диапазон [0:9]
// как будто v в диапазоне [1:10]:
for (int i = 1; i<=10; i++) {
v[i-1] = ... // не забыть пересчитать индекс
}
// ...
}
Лучшее решение дает класс vec c произвольными границами индекса:
class vec : public vector {
int lb;
public:
vec(int low, int high)
: vector(high-low+1) { lb=low; }
int& operator[](int i)
{ return vector::operator[](i-lb); }
int low() { return lb; }
int high() { return lb+size() - 1; }
};
Класс vec можно использовать без дополнительных операций, необходимых
в первом примере:
void g()
{
vec v(1,10); // диапазон [1:10]
for (int i = 1; i<=10; i++) {
v[i] = ...
}
// ...
}
Очевидно, вариант с классом vec нагляднее и безопаснее.
Интерфейсные классы имеют и другие важные области применения,
например, интерфейс между программами на С++ и программами на другом
языке ($$12.1.4) или интерфейс с особыми библиотеками С++.
Концепция абстрактного класса дает эффективное средство для разделения
интерфейса и его реализации. Мы применяли эту концепцию и получали
постоянную связь между интерфейсом, заданным абстрактным типом,
и реализацией, представленной конкретным типом. Так, невозможно
переключить абстрактный итератор с одного класса-источника на
другой, например, если исчерпано множество (класс set), невозможно
перейти на потоки.
Далее, пока мы работаем с объектами абстрактного типа с помощью
указателей или ссылок, теряются все преимущества виртуальных
функций. Программа пользователя начинает зависеть от конкретных классов
реализации. Действительно, не зная размера объекта, даже при
абстрактном типе нельзя разместить объект в стеке, передать как параметр
по значению или разместить как статический. Если работа с объектами
организована через указатели или ссылки, то задача распределения
памяти перекладывается на пользователя ($$13.10).
Существует и другое ограничение, связанное с использованием абстрактных
типов. Объект такого класса всегда имеет определенный размер,
но классы, отражающие реальное понятие, могут требовать память
разных размеров.
Есть распространенный прием преодоления этих трудностей, а именно,
разбить отдельный объект на две части: управляющую, которая определяет
интерфейс объекта, и содержательную, в которой находятся все
или большая часть атрибутов объекта. Связь между двумя частями
реализуется с помощью указателя в управляющей части на содержательную
часть. Обычно в управляющей части кроме указателя есть
и другие данные, но их немного. Суть в том, что состав управляющей
части не меняется при изменении содержательной части, и она
настолько мала, что можно свободно работать с самими объектами,
а не с указателями или ссылками на них.
управляющая часть содержательная часть
Простым примером управляющего класса может служить класс string из
$$7.6. В нем содержится интерфейс, контроль доступа и управление
памятью для содержательной части. В этом примере управляющая и
содержательная части представлены конкретными типами, но чаще
содержательная часть представляется абстрактным классом.
Теперь вернемся к абстрактному типу set из $$13.3. Как можно
определить управляющий класс для этого типа, и какие это даст плюсы
и минусы? Для данного класса set можно определить управляющий
класс просто перегрузкой операции ->:
class set_handle {
set* rep;
public:
set* operator->() { return rep; }
set_handler(set* pp) : rep(pp) { }
};
Это не слишком влияет на работу с множествами, просто передаются
объекты типа set_handle вместо объектов типа set& или set*,
например:
void my(set_handle s)
{
for (T* p = s->first(); p; p = s->next())
{
// ...
}
// ...
}
void your(set_handle s)
{
for (T* p = s->first(); p; p = s->next())
{
// ...
}
// ...
}
void user()
{
set_handle sl(new slist_set);
set_handle v(new vector_set v(100));
my(sl);
your(v);
my(v);
your(sl);
}
Если классы set и set_handle разрабатывались совместно,легко
реализовать подсчет числа создаваемых множеств:
class set {
friend class set_handle;
protected:
int handle_count;
public:
virtual void insert(T*) = 0;
virtual void remove(T*) = 0;
virtual int is_member(T*) = 0;
virtual T* first() = 0;
virtual T* next() = 0;
set() : handle_count(0) { }
};
Чтобы подсчитать число объектов данного типа set, в управляющем
классе нужно увеличивать или уменьшать значение счетчика
set_handle:
class set_handle {
set* rep;
public:
set* operator->() { return rep; }
set_handle(set* pp)
: rep(pp) { pp->handle_count++; }
set_handle(const set_handle& r)
: rep(r.rep) { rep->handle_count++; }
set_handle& operator=(const set_handle& r)
{
rep->handle_count++;
if (--rep->handle_count == 0) delete rep;
rep = r.rep;
return *this;
}
~set_handle()
{ if (--rep->handle_count == 0) delete rep; }
};
Если все обращения к классу set обязательно идут через
set_handle, пользователь может не беспокоиться о распределении
памяти под объекты типа set.
На практике иногда приходится извлекать указатель на содержательную
часть из управляющего класса и пользоваться непосредственно им.
Можно, например, передать такой указатель функции, которая ничего
не знает об управляющем классе. Если функция не уничтожает объект,
на который она получила указатель, и если она не сохраняет указатель
для дальнейшего использования после возврата, никаких ошибок быть
не должно. Может оказаться полезным переключение управляющего класса
на другую содержательную часть:
class set_handle {
set* rep;
public:
// ...
set* get_rep() { return rep; }
void bind(set* pp)
{
pp->handle_count++;
if (--rep->handle_count == 0) delete rep;
rep = pp;
}
};
Создание новых производных от set_handle классов обычно не имеет
особого смысла, поскольку это - конкретный тип без виртуальных
функций. Другое дело - построить управляющий класс для семейства
классов, определяемых одним базовым. Полезным приемом будет
создание производных от такого управляющего класса. Этот прием можно
применять как для узловых классов, так и для абстрактных типов.
Естественно задавать управляющий класс как шаблон типа:
template<class T> class handle {
T* rep;
public:
T* operator->() { return rep; }
// ...
};
Но при таком подходе требуется взаимодействие между
управляющим и "управляемым" классами. Если управляющий и управляемые
классы разрабатываются совместно, например, в процессе создания
библиотеки, то это может быть допустимо. Однако, существуют и другие
решения ($$13.10).
За счет перегрузки операции -> управляющий класс получает
возможность контроля и выполнения каких-то операций при каждом
обращении к объекту. Например, можно вести подсчет частоты
использования объектов через управляющий класс:
template<class T>
class Xhandle {
T* rep;
int count;
public:
T* operator->() { count++; return rep; }
// ...
};
Нужна более сложная техника, если требуется выполнять операции как
перед, так и после обращения к объекту. Например, может потребоваться
множество с блокировкой при выполнении операций добавления к
множеству и удаления из него. Здесь, по сути, в управляющем классе
приходится дублировать интерфейс с объектами содержательной части:
class set_controller {
set* rep;
// ...
public:
lock();
unlock();
virtual void insert(T* p)
{ lock(); rep->insert(p); unlock(); }
virtual void remove(T* p)
{ lock(); rep->remove(p); unlock(); }
virtual int is_member(T* p)
{ return rep->is_member(p); }
virtual T* first() { return rep->first(); }
virtual T* next() { return rep->next(); }
// ...
};
Писать функции-переходники для всего интерфейса утомительно (а значит
могут появляться ошибки), но не трудно и это не ухудшает
характеристик программы.
Заметим, что не все функции из set следует блокировать. Как
показывает опыт автора, типичный случай, когда операции до и после
обращения к объекту надо выполнять не для всех, а только для некоторых
функций-членов. Блокировка всех операций, как это делается в
мониторах некоторых операционных систем, является избыточной и может
существенно ухудшить параллельный режим выполнения.
Переопределив все функции интерфейса в управляющем классе, мы
получили по сравнению с приемом перегрузки операции ->, то
преимущество, что теперь можно строить производные
от set_controller классы. К сожалению, мы можем потерять и некоторые
достоинства управляющего класса, если к производным классам будут
добавляться члены, представляющие данные. Можно сказать, что
программный объем, который разделяется между управляемыми классами
уменьшается по мере роста программного объема управляющего класса.
При проектировании библиотеки или просто программы с большим временем
счета один из ключевых вопросов связан с управлением памятью.
В общем случае создатель библиотеки не знает, в каком окружении она
будет работать. Будет ли там ресурс памяти настолько критичен, что ее
нехватка станет серьезной проблемой, или же серьезной помехой станут
накладные расходы, связанные с управлением памятью?
Один из основных вопросов управления памятью можно сформулировать
так: если функция f() передает или возвращает указатель на объект, то
кто должен уничтожать этот объект? Необходимо ответить и на связанный
с ним вопрос: в какой момент объект может быть уничтожен? Ответы на эти
вопросы особенно важны для создателей и пользователей таких контейнеров,
как списки, массивы и ассоциативные массивы. С точки зрения
создателя библиотеки идеальными будут ответы: "Система" и "В тот момент,
когда объект больше никто не использует". Когда система уничтожает
объект, обычно говорят, что она занимается сборкой мусора, а та часть
системы, которая определяет, что объект больше никем не используется,
и уничтожает его, называется сборщиком мусора.
К сожалению, использование сборщика мусора может повлечь за собой
накладные расходы на время счета и память, прерывания полезных
функций, определенную аппаратную поддержку, трудности связывания
частей программы на разных языках или просто усложнение системы.
Многие пользователи не могут позволить себе этого.Ь
Ь Говорят, что программисты на Лиспе знают, насколько важно управление
памятью, и поэтому не могут отдать его пользователю. Программисты
на С тоже знают, насколько важно управление памятью, и поэтому не
могут оставить его системе.
Поэтому в большинстве программ на С++ не приходится рассчитывать
на сборщик мусора и нужно предложить свою стратегию размещения
объектов в свободной памяти, не обращаясь к системе. Но реализации
С++ со сборщиком мусора все-таки существуют.
Рассмотрим самую простую схему управления памятью для программ
на С++. Для этого заменим operator new() на тривиальную функцию
размещения, а operator delete() - на пустую функцию:
inline size_t align(size_t s)
/*
Даже в простой функции размещения нужно
выравнивание памяти, чтобы на объект
можно было настроить указатель
произвольного типа
*/
{
union Word { void* p; long double d; long l; }
int x = s + sizeof(Word) - 1;
x -= x%sizeof(Word);
return x;
}
static void* freep; // настроим start на свободную память
void* operator new(size_t s) // простая линейная функция размещения
{
void* p = freep;
s = align(s);
freep += s;
return p;
}
void operator delete(void*) { } // пусто
Если память бесконечна, то наше решение дает сборщик мусора без
всяких сложностей и накладных расходов. Такой подход не применим
для библиотек, когда заранее неизвестно, каким образом будет
использоваться память, и когда программа, пользующаяся библиотекой,
будет иметь большое время счета. Такой способ выделения памяти
идеально подходит для программ, которым требуется ограниченный объем
памяти или объем, пропорциональный размеру входного потока данных.
Сборку мусора можно рассматривать как моделирование бесконечной
памяти на памяти ограниченного размера. Помня об этом, можно
ответить на типичный вопрос: должен ли сборщик мусора вызывать
деструктор для тех объектов, память которых он использует? Правильный
ответ - нет, поскольку, если размещенный в свободной памяти объект
не был удален, то он не будет и уничтожен. Исходя из этого, операцию
delete можно рассматривать как запрос на вызов деструктора (и еще это
- сообщение системе, что память объекта можно использовать). Но как
быть, если действительно требуется уничтожить размещенный в свободной
памяти объект, который не был удален? Заметим, что для
статических и автоматических объектов такой вопрос не встает, -
деструкторы для них неявно вызываются всегда. Далее, уничтожение
объекта "во время сборки мусора" по сути является
операцией с непредсказуемым результатом. Она может совершиться
в любое время между последним использованием объекта и "концом
программы"Ь, а значит, в каком состоянии будет программа в этот момент
неизвестно.
Ь Здесь использованы кавычки, потому что трудно точно определить,
что такое конец программы. (прим. перев.)
Трудно правильно запрограммировать такие операции и они не так полезны,
как кажется.
Задачу уничтожения объектов, если время этой операции точно не задано,
можно решить с помощью программы обслуживания заявок на уничтожение. Назовем
ее сервером заявок. Если объект необходимо уничтожить в конце программы,
то надо записать в глобальный ассоциативный массив его адрес и
указатель на функцию "очистки". Если объект удален явной операцией,
заявка аннулируется. При уничтожении самого сервера (в конце
программы) вызываются функции очистки для всех оставшихся заявок.
Это решение подходит и для сборки мусора, поскольку мы рассматриваем
ее как моделирование бесконечной памяти. Для сборщика мусора нужно
выбрать одно из двух решений: либо удалять объект, когда единственной
оставшейся ссылкой на него будет ссылка, находящаяся в массиве самого
сервера, либо (стандартное решение) не удалять объект до конца
программы, поскольку все-таки ссылка на него есть.
Сервер заявок можно реализовать как ассоциативный массив ($$8.8):
class Register {
Map<void*, void (*) (void*)> m;
public:
insert(void* po, void(*pf)()) { m[po]=pf; }
remove(void* po) { m.remove(po); }
};
Register cleanup_register;
Класс, постоянно обращающийся к серверу, может выглядеть так:
class X {
// ...
static void cleanup(void*);
public:
X()
{
cleanup_register.insert(this,&cleanup);
// ...
}
~X() { cleanup(this); }
// ...
};
void X::cleanup(void* pv)
{
X* px = (X*)pv;
cleanup_register.remove(pv);
// очистка
}
Чтобы в классе Register не иметь дела с типами, мы использовали
статическую функцию-член с указателем типа void*.
Допустим, что у нас нет бесконечной памяти и сборщика мусора. На какие
средства управления памятью может рассчитывать создатель
контейнера, например, класса Vector? Для случая таких простых элементов,
как int, очевидно, надо просто копировать их в контейнер. Столь же
очевидно, что для других типов, таких, как абстрактный класс Shape,
в контейнере следует хранить указатель. Создатель библиотеки
должен предусмотреть оба варианта. Приведем набросок очевидного
решения:
template<class T> Vector {
T* p;
int sz;
public:
Vector(int s) { p = new T[sz=s]; }
// ...