Страница:
};
Если пользователь не будет заносить в контейнер вместо указателей на
объекты сами объекты типа Shape, то это решение подходит для обоих
вариантов.
Vector<Shape*> vsp(200); // нормально
Vector<Shape> vs(200); // ошибка при трансляции
К счастью, транслятор отслеживает попытку создать массив объектов
абстрактного базового класса Shape.
Однако, если используются указатели, создатель библиотеки и
пользователь должны договориться, кто будет удалять хранимые
в контейнере объекты. Рассмотрим пример:
void f()
// противоречивое использование средств
// управления памятью
{
Vector<Shape*> v(10);
Circle* cp = new Circle;
v[0] = cp;
v[1] = new Triangle;
Square s;
v[2] = &s;
delete cp; // не удаляет объекты, на которые настроены
// указатели, находящиеся в контейнере
}
Если использовать реализацию класса Vector из $$1.4.3, объект
Triangle в этом примере навсегда останется в подвешенном состоянии
(на него нет указателей), если только нет сборщика мусора.
Главное в управлении памятью это - это корректность. Рассмотрим такой
пример:
void g()
// корректное использование средств управления памятью
{
Vector<Shape*> v(10);
Circle* cp = new Circle;
v[0] = cp;
v[1] = new Triangle;
Square s;
v[2] = &s;
delete cp;
delete v[1];
}
Рассмотрим теперь такой векторный класс,который следит за удалением
занесенных в него указателей:
template<class T> MVector {
T* p;
int sz;
public:
MVector(int s);
~MVector();
// ...
};
template<class T> MVector<T>::MVector(int s)
{
// проверка s
p = new T[sz=s];
for (int i = 0; i<s; i++) p[i] = 0;
}
template<class T> MVector<T>::~MVector()
{
for (int i = 0; i<s; i++) delete p[i];
delete p;
}
Пользователь может рассчитывать, что содержащиеся в MVector указатели
будут удалены. Отсюда следует, что после удаления MVector пользователь
не должен обращаться с помощью указателей к объектам, заносившимся в этот
контейнер. В момент уничтожения MVector в нем не должно быть
указателей на статические или автоматические объекты, например:
void h()
// корректное использование средств управления памятью
{
MVector<Shape*> v(10);
Circle* cp = new circle();
v[0] = cp;
v[1] = new Triangle;
Square s;
v[2] = &s;
v[2] = 0; // предотвращает удаление s
// все оставшиеся указатели
// автоматически удаляются при выходе
}
Естественно, такое решение годится только для контейнеров, в
которых не содержатся копии объектов, а для класса Map ($$8.8),
например, оно не годится. Здесь приведен простой вариант деструктора
для MVector, но содержится ошибка, поскольку один и тот же указатель,
дважды занесенный в контейнер, будет удаляться тоже два раза.
Построение и уничтожение таких контейнеров, которые следят
за удалением содержащихся в них объектах, довольно дорогостоящая
операция. Копирование же этих контейнеров следует запретить
или, по крайней мере, сильно ограничить (действительно, кто
будет отвечать за удаление контейнер или его копия?):
template<class T> MVector {
// ...
private:
MVector(const MVector&); //предотвращает копирование
MVector& operator=(const MVector&); //то же самое
// ...
};
Отсюда следует, что такие контейнеры надо передавать по ссылке
или указателю (если, вообще, это следует делать), но тогда в управлении
памятью возникает трудность другого рода.
Часто бывает полезно уменьшить число указателей, за которыми
должен следить пользователь. Действительно, намного проще следить
за 100 объектами первого уровня, которые, в свою очередь, управляют
1000 объектов нулевого уровня, чем непосредственно работать с
1100 объектами. Собственно, приведенные в этом разделе приемы,
как и другие приемы, используемые для управления памятью, сводятся
к стандартизации и универсализации за счет применения конструкторов
и деструкторов. Это позволяет свести задачу
управления памятью для практически невообразимого числа объектов,
скажем 100 000, до вполне управляемого числа, скажем 100.
Можно ли таким образом определить класс контейнера, чтобы
программист, создающий объект типа контейнера, мог выбрать
стратегию управления памятью из нескольких возможных, хотя определен
контейнер только одного типа? Если это возможно, то будет ли оправдано?
На второй вопрос ответ положительный, поскольку большинство функций
в системе вообще не должны заботиться о распределении памяти.
Существование же нескольких разных типов для каждого контейнерного
класса является для пользователя ненужным усложнением. В библиотеке должен
быть или один вид контейнеров (Vector или MVector), или же оба, но
представленные как варианты одного типа, например:
template<class T> PVector {
T** p;
int sz;
int managed;
public:
PVector(int s, int managed = 0 );
~PVector();
// ...
};
template<class T> PVector<T>::PVector(int s, int m)
{
// проверка s
p = new T*[sz=s];
if (managed = m)
for (int i = 0; i<s; i++) p[i] = 0;
}
template<class T> PVector<T>::~PVector()
{
if (managed) {
for (int i = 0; i<s; i++) delete p[i];
}
delete p;
}
Примером класса, который может предложить библиотека для облегчения
управления памятью, является управляющий класс из $$13.9. Раз в
управляющем классе ведется подсчет ссылок на него, можно спокойно
передавать объект этого класса, не думая о том, кто будет
удалять доступные через него объекты. Это сделает сам объект управляющего
класса. Но такой подход требует, чтобы в управляемых объектах было поле
для подсчета числа использований. Введя дополнительный объект, можно
просто снять это жесткое требование:
template<class T>
class Handle {
T* rep;
int* pcount;
public:
T* operator->() { return rep; }
Handle(const T* pp)
: rep(pp), pcount(new int) { (*pcount) = 0; }
Handle(const Handle& r)
: rep(r.rep), pcount(r.count) { (*pcount)++; }
void bind(const Handle& r)
{
if (rep == r.rep) return;
if (--(*pcount) == 0) { delete rep; delete pcount; }
rep = r.rep;
pcount = r.pcount;
(*pcount)++;
}
Handle& operator=(const Handle& r)
{
bind(r);
return *this;
}
~Handle()
{
if (--(*pcount) == 0) { delete rep; delete pcount; }
}
};
Во всех приведенных примерах память рассматривалась как нечто данное.
Однако, обычная функция общего назначения для распределения свободной
памяти оказывается до удивления менее эффективной, чем функция размещения
специального назначения. Вырожденным случаем таких функций можно
считать приведенный пример с размещением в "бесконечной" памяти и
с пустой функцией освобождения. В библиотеке могут быть более
содержательные функции размещения, и бывает, что с их помощью
удается удвоить скорость выполнения программы. Но прежде, чем пытаться
с их помощью оптимизировать программу, запустите для нее профилировщик,
чтобы выявить накладные расходы, связанные с выделением памяти.
В разделах $$5.5.6 и $$6.7 было показано как с помощью определения
функций X::operator new() и X::operator delete() можно использовать
функцию размещения для объектов класса X. Здесь есть определенная
трудность. Для двух классов X и Y функции размещения могут быть
настолько сходными, что желательно иметь одну такую функцию.
Иными словами, желательно иметь в библиотеке такой класс, который
предоставляет функции размещения и освобождения, пригодные для размещения
объектов данного класса. Если такой класс есть, то функции размещения
и освобождения для данного класса получаются за счет привязки к нему
общих функций размещения и освобождения:
class X {
static Pool my_pool;
// ...
public:
// ...
void* operator new(size_t) { return my_pool.alloc(); }
void operator delete(void* p) { my_pool.free(p); }
};
Pool X::my_pool(sizeof(X));
С помощью класса Pool память распределяется блоками одного размера.
В приведенном примере объект my_pool отводит память блоками
размером sizeof(X).
Составляется описание класса X и используется Pool с учетом оптимизации
скорости программы и компактности представления. Обратите внимание,
что размер выделяемых блоков памяти является для класса "встроенным",
поэтому задающий размер параметр функции X::operator new() не
используется. Используется вариант функции X::operator delete()
без параметра. Если класс Y является производным класса X, и
sizeof(Y)>sizeof(X), то для класса Y должны быть свои функции
размещения и освобождения. Наследование функций класса X приведет
к катастрофе. К счастью, задать такие функции для Y очень просто.
Класс Pool предоставляет связанный список элементов требуемого
размера. Элементы выделяются из блока памяти фиксированного размера
и по мере надобности запрашиваются новые блоки памяти. Элементы
группируются большими блоками, чтобы минимизировать число обращений
за памятью к функции размещения общего назначения. До тех пор пока
не будет уничтожен сам объект PooL, память никогда не возвращается
функции размещения общего назначения.
Приведем описание класса Pool:
class Pool {
struct Link { Link* next; }
const unsigned esize;
Link* head;
Pool(Pool&); // защита от копирования
void operator= (Pool&); // защита от копирования
void grow();
public:
Pool(unsigned n);
~Pool();
void* alloc();
void free(void* b);
};
inline void* Pool::alloc()
{
if (head==0) grow();
Link* p = head;
head = p->next;
return p;
}
inline void Pool::free(void* b)
{
Link* p = (Link*) b;
p->next = head;
head = p;
}
Приведенные описания логично поместить в заголовочный файл Pool.h.
Следующие определения могут находиться в любом месте программе и
завершают наш пример. Объект Pool должен инициализироваться
конструктором:
Pool::Pool(unsigned sz)
: esize(sz)
{
head = 0;
}
Функция Pool::grow() будет связывать все элементы в список квантов
свободной памяти head, образуя из них новый блок. Определения
остальных функций-членов оставлены в качестве упражнений 5 и 6 в
$$13.11.
void Pool::grow()
{
const int overhead = 12;
const int chunk_size = 8*1024-overhead;
const int nelem = (chunk_size-esize)/esize;
char* start = new char[chunk_size];
char* last = &start[(nelem-1)*esize];
for (char* p = start; p<last; p+=esize)
((Link*)p)->next = ((Link*)p)+1;
((Link*)last)->next = 0;
head = (Link*)start;
}
1. (*3) Завершите определения функций-членов класса Type_info.
2. (*3) Предложите такую структуру объекта Type_info, чтобы функция
Type_info::get_info() стала лишней, и перепишите с учетом этого
функции-члены Type_info.
3. (*2.5) Насколько наглядно вы сможете записать примеры с Dialog_box,
не используя макроопределения (а также расширения языка)? Насколько
наглядно вам удастся записать их, используя расширения языка?
4. (*4) Исследуйте две широко распространенные библиотеки.
Классифицируйте все библиотечные классы, разбив их на: конкретные
типы, абстрактные типы, узловые классы, управляющие классы и
интерфейсные классы. Используются ли абстрактные узловые классы
и конкретные узловые классы? Можно ли предложить более подходящее
разбиение классов этих библиотек? Используется ли обширный
интерфейс? Какие имеются средства динамической информации о типе
(если они есть)? Какова стратегия управления памятью?
5. (*3) Определите шаблонный вариант класса Pool из $$13.10.3. Пусть
размер выделяемого элемента памяти будет параметром шаблона
типа, а не конструктора.
6. (*2.5) Усовершенствуйте шаблон типа Pool из предыдущего упражнения
так, чтобы некоторые элементы размещались во время работы конструктора.
Сформулируйте в чем будет проблема переносимости, если использовать
Pool с типом элементов char, покажите как ее устранить.
7. (*3) Если ваша версия С++ прямо не поддерживает динамические
запросы о типе, обратитесь к своей основной библиотеке. Реализован
ли там механизм динамических запросов о типе? Если это так,
задайте операции из $$13.5 как надстройку над этим механизмом.
8. (*2.5) Определите такой строковый класс, в котором нет никакого
динамического контроля, и второй производный от него строковый
класс, который только проводит динамический контроль и обращается
к первому. Укажите плюсы и минусы такого решения по сравнению
с решением,в котором делается выборочный динамический контроль,
сравните с подходом, использующим инварианты, как было предложено
в $$12.2.7.1. Насколько можно совмещать эти подходы?
9. (*4) Определите класс Storable как абстрактный базовый класс с
виртуальными функциями writeout() и readin(). Для простоты
допустим, что для задания нужного адресного пространства достаточно
строки символов. С помощью класса Storable реализуйте
обмен объектами с диском. Проверьте его на объектах нескольких
классов по своему усмотрению.
10.(*4) Определите базовый класс Persistent с операциями save()
и nosave(), который будет проверять, что деструктор создал объект
в определенной памяти. Какие еще полезные операции можно предложить?
Проверьте класс Persistent на нескольких классах по своему выбору.
Является ли класс Persistent узловым классом, конкретным или
абстрактным типом? Аргументируйте ответ.
11.(*3) Составьте только описание класса stack, который реализует
стек с помощью операций create() (создать стек), delete()
(уничтожить стек), push() (записать в стек) и pop() (читать из
стека). Используйте только статические члены. Для привязки и
обозначения стеков определите класс id. Гарантируйте, что
пользователь сможет копировать объекты stack::id, но не сможет
работать с ними иным способом. Сравните это определение стека
с классом stack из $$8.2.
12.(*3) Составьте описание класса stack, который является абстрактным
типом ($$13.3). Предложите две различные реализации для интерфейса,
заданного stack. Напишите небольшую программу, работающую с
этими классами. Сравните это решение с классами, определяющими
стек, из предыдущего упражнения и из $$8.2.
13.(*3) Составьте такое описание класса stack, для которого можно
в динамике менять реализацию. Подсказка: "Всякую задачу можно
решить, введя еще одну косвенность".
14.(*3.5) Определите класс Oper, содержащий идентификатор (некоторого
подходящего типа) и операцию (некоторый указатель на функцию).
Определите класс cat_object, содержащий список объектов Oper и
объект типа void*. Задайте в классе cat_object операции:
add_oper(), которая добавляет объект к списку; remove_oper(id),
которая удаляет из списка объект Oper c идентификатором id;
operator() (id,arg), которая вызывает функцию из объекта Oper c
идентификатором id. Реализуйте с помощью класса cat_object
стек объектов Oper. Напишите небольшую программу, работающую
с этими классами.
15.(*3) Определите шаблон типа Object, служащий базовым классом
для cat_object. С помощью Object реализуйте стек для объектов
класса String. Напишите небольшую программу, использующую этот
шаблон типа.
16.(*3) Определите вариант класса Object под именем Class, в котором
объекты с одинаковым идентификатором имеют общий список операций.
Напишите небольшую программу, использующую этот шаблон типа.
17.(*3) Определите шаблон типа Stack, который задает традиционный
и надежный интерфейс со стеком, реализуемым объектом шаблона
типа Object. Сравните это определение стека с классами, задающими
стек, из предыдущих упражнений. Напишите небольшую программу,
использующую этот шаблон типа.
Если пользователь не будет заносить в контейнер вместо указателей на
объекты сами объекты типа Shape, то это решение подходит для обоих
вариантов.
Vector<Shape*> vsp(200); // нормально
Vector<Shape> vs(200); // ошибка при трансляции
К счастью, транслятор отслеживает попытку создать массив объектов
абстрактного базового класса Shape.
Однако, если используются указатели, создатель библиотеки и
пользователь должны договориться, кто будет удалять хранимые
в контейнере объекты. Рассмотрим пример:
void f()
// противоречивое использование средств
// управления памятью
{
Vector<Shape*> v(10);
Circle* cp = new Circle;
v[0] = cp;
v[1] = new Triangle;
Square s;
v[2] = &s;
delete cp; // не удаляет объекты, на которые настроены
// указатели, находящиеся в контейнере
}
Если использовать реализацию класса Vector из $$1.4.3, объект
Triangle в этом примере навсегда останется в подвешенном состоянии
(на него нет указателей), если только нет сборщика мусора.
Главное в управлении памятью это - это корректность. Рассмотрим такой
пример:
void g()
// корректное использование средств управления памятью
{
Vector<Shape*> v(10);
Circle* cp = new Circle;
v[0] = cp;
v[1] = new Triangle;
Square s;
v[2] = &s;
delete cp;
delete v[1];
}
Рассмотрим теперь такой векторный класс,который следит за удалением
занесенных в него указателей:
template<class T> MVector {
T* p;
int sz;
public:
MVector(int s);
~MVector();
// ...
};
template<class T> MVector<T>::MVector(int s)
{
// проверка s
p = new T[sz=s];
for (int i = 0; i<s; i++) p[i] = 0;
}
template<class T> MVector<T>::~MVector()
{
for (int i = 0; i<s; i++) delete p[i];
delete p;
}
Пользователь может рассчитывать, что содержащиеся в MVector указатели
будут удалены. Отсюда следует, что после удаления MVector пользователь
не должен обращаться с помощью указателей к объектам, заносившимся в этот
контейнер. В момент уничтожения MVector в нем не должно быть
указателей на статические или автоматические объекты, например:
void h()
// корректное использование средств управления памятью
{
MVector<Shape*> v(10);
Circle* cp = new circle();
v[0] = cp;
v[1] = new Triangle;
Square s;
v[2] = &s;
v[2] = 0; // предотвращает удаление s
// все оставшиеся указатели
// автоматически удаляются при выходе
}
Естественно, такое решение годится только для контейнеров, в
которых не содержатся копии объектов, а для класса Map ($$8.8),
например, оно не годится. Здесь приведен простой вариант деструктора
для MVector, но содержится ошибка, поскольку один и тот же указатель,
дважды занесенный в контейнер, будет удаляться тоже два раза.
Построение и уничтожение таких контейнеров, которые следят
за удалением содержащихся в них объектах, довольно дорогостоящая
операция. Копирование же этих контейнеров следует запретить
или, по крайней мере, сильно ограничить (действительно, кто
будет отвечать за удаление контейнер или его копия?):
template<class T> MVector {
// ...
private:
MVector(const MVector&); //предотвращает копирование
MVector& operator=(const MVector&); //то же самое
// ...
};
Отсюда следует, что такие контейнеры надо передавать по ссылке
или указателю (если, вообще, это следует делать), но тогда в управлении
памятью возникает трудность другого рода.
Часто бывает полезно уменьшить число указателей, за которыми
должен следить пользователь. Действительно, намного проще следить
за 100 объектами первого уровня, которые, в свою очередь, управляют
1000 объектов нулевого уровня, чем непосредственно работать с
1100 объектами. Собственно, приведенные в этом разделе приемы,
как и другие приемы, используемые для управления памятью, сводятся
к стандартизации и универсализации за счет применения конструкторов
и деструкторов. Это позволяет свести задачу
управления памятью для практически невообразимого числа объектов,
скажем 100 000, до вполне управляемого числа, скажем 100.
Можно ли таким образом определить класс контейнера, чтобы
программист, создающий объект типа контейнера, мог выбрать
стратегию управления памятью из нескольких возможных, хотя определен
контейнер только одного типа? Если это возможно, то будет ли оправдано?
На второй вопрос ответ положительный, поскольку большинство функций
в системе вообще не должны заботиться о распределении памяти.
Существование же нескольких разных типов для каждого контейнерного
класса является для пользователя ненужным усложнением. В библиотеке должен
быть или один вид контейнеров (Vector или MVector), или же оба, но
представленные как варианты одного типа, например:
template<class T> PVector {
T** p;
int sz;
int managed;
public:
PVector(int s, int managed = 0 );
~PVector();
// ...
};
template<class T> PVector<T>::PVector(int s, int m)
{
// проверка s
p = new T*[sz=s];
if (managed = m)
for (int i = 0; i<s; i++) p[i] = 0;
}
template<class T> PVector<T>::~PVector()
{
if (managed) {
for (int i = 0; i<s; i++) delete p[i];
}
delete p;
}
Примером класса, который может предложить библиотека для облегчения
управления памятью, является управляющий класс из $$13.9. Раз в
управляющем классе ведется подсчет ссылок на него, можно спокойно
передавать объект этого класса, не думая о том, кто будет
удалять доступные через него объекты. Это сделает сам объект управляющего
класса. Но такой подход требует, чтобы в управляемых объектах было поле
для подсчета числа использований. Введя дополнительный объект, можно
просто снять это жесткое требование:
template<class T>
class Handle {
T* rep;
int* pcount;
public:
T* operator->() { return rep; }
Handle(const T* pp)
: rep(pp), pcount(new int) { (*pcount) = 0; }
Handle(const Handle& r)
: rep(r.rep), pcount(r.count) { (*pcount)++; }
void bind(const Handle& r)
{
if (rep == r.rep) return;
if (--(*pcount) == 0) { delete rep; delete pcount; }
rep = r.rep;
pcount = r.pcount;
(*pcount)++;
}
Handle& operator=(const Handle& r)
{
bind(r);
return *this;
}
~Handle()
{
if (--(*pcount) == 0) { delete rep; delete pcount; }
}
};
Во всех приведенных примерах память рассматривалась как нечто данное.
Однако, обычная функция общего назначения для распределения свободной
памяти оказывается до удивления менее эффективной, чем функция размещения
специального назначения. Вырожденным случаем таких функций можно
считать приведенный пример с размещением в "бесконечной" памяти и
с пустой функцией освобождения. В библиотеке могут быть более
содержательные функции размещения, и бывает, что с их помощью
удается удвоить скорость выполнения программы. Но прежде, чем пытаться
с их помощью оптимизировать программу, запустите для нее профилировщик,
чтобы выявить накладные расходы, связанные с выделением памяти.
В разделах $$5.5.6 и $$6.7 было показано как с помощью определения
функций X::operator new() и X::operator delete() можно использовать
функцию размещения для объектов класса X. Здесь есть определенная
трудность. Для двух классов X и Y функции размещения могут быть
настолько сходными, что желательно иметь одну такую функцию.
Иными словами, желательно иметь в библиотеке такой класс, который
предоставляет функции размещения и освобождения, пригодные для размещения
объектов данного класса. Если такой класс есть, то функции размещения
и освобождения для данного класса получаются за счет привязки к нему
общих функций размещения и освобождения:
class X {
static Pool my_pool;
// ...
public:
// ...
void* operator new(size_t) { return my_pool.alloc(); }
void operator delete(void* p) { my_pool.free(p); }
};
Pool X::my_pool(sizeof(X));
С помощью класса Pool память распределяется блоками одного размера.
В приведенном примере объект my_pool отводит память блоками
размером sizeof(X).
Составляется описание класса X и используется Pool с учетом оптимизации
скорости программы и компактности представления. Обратите внимание,
что размер выделяемых блоков памяти является для класса "встроенным",
поэтому задающий размер параметр функции X::operator new() не
используется. Используется вариант функции X::operator delete()
без параметра. Если класс Y является производным класса X, и
sizeof(Y)>sizeof(X), то для класса Y должны быть свои функции
размещения и освобождения. Наследование функций класса X приведет
к катастрофе. К счастью, задать такие функции для Y очень просто.
Класс Pool предоставляет связанный список элементов требуемого
размера. Элементы выделяются из блока памяти фиксированного размера
и по мере надобности запрашиваются новые блоки памяти. Элементы
группируются большими блоками, чтобы минимизировать число обращений
за памятью к функции размещения общего назначения. До тех пор пока
не будет уничтожен сам объект PooL, память никогда не возвращается
функции размещения общего назначения.
Приведем описание класса Pool:
class Pool {
struct Link { Link* next; }
const unsigned esize;
Link* head;
Pool(Pool&); // защита от копирования
void operator= (Pool&); // защита от копирования
void grow();
public:
Pool(unsigned n);
~Pool();
void* alloc();
void free(void* b);
};
inline void* Pool::alloc()
{
if (head==0) grow();
Link* p = head;
head = p->next;
return p;
}
inline void Pool::free(void* b)
{
Link* p = (Link*) b;
p->next = head;
head = p;
}
Приведенные описания логично поместить в заголовочный файл Pool.h.
Следующие определения могут находиться в любом месте программе и
завершают наш пример. Объект Pool должен инициализироваться
конструктором:
Pool::Pool(unsigned sz)
: esize(sz)
{
head = 0;
}
Функция Pool::grow() будет связывать все элементы в список квантов
свободной памяти head, образуя из них новый блок. Определения
остальных функций-членов оставлены в качестве упражнений 5 и 6 в
$$13.11.
void Pool::grow()
{
const int overhead = 12;
const int chunk_size = 8*1024-overhead;
const int nelem = (chunk_size-esize)/esize;
char* start = new char[chunk_size];
char* last = &start[(nelem-1)*esize];
for (char* p = start; p<last; p+=esize)
((Link*)p)->next = ((Link*)p)+1;
((Link*)last)->next = 0;
head = (Link*)start;
}
1. (*3) Завершите определения функций-членов класса Type_info.
2. (*3) Предложите такую структуру объекта Type_info, чтобы функция
Type_info::get_info() стала лишней, и перепишите с учетом этого
функции-члены Type_info.
3. (*2.5) Насколько наглядно вы сможете записать примеры с Dialog_box,
не используя макроопределения (а также расширения языка)? Насколько
наглядно вам удастся записать их, используя расширения языка?
4. (*4) Исследуйте две широко распространенные библиотеки.
Классифицируйте все библиотечные классы, разбив их на: конкретные
типы, абстрактные типы, узловые классы, управляющие классы и
интерфейсные классы. Используются ли абстрактные узловые классы
и конкретные узловые классы? Можно ли предложить более подходящее
разбиение классов этих библиотек? Используется ли обширный
интерфейс? Какие имеются средства динамической информации о типе
(если они есть)? Какова стратегия управления памятью?
5. (*3) Определите шаблонный вариант класса Pool из $$13.10.3. Пусть
размер выделяемого элемента памяти будет параметром шаблона
типа, а не конструктора.
6. (*2.5) Усовершенствуйте шаблон типа Pool из предыдущего упражнения
так, чтобы некоторые элементы размещались во время работы конструктора.
Сформулируйте в чем будет проблема переносимости, если использовать
Pool с типом элементов char, покажите как ее устранить.
7. (*3) Если ваша версия С++ прямо не поддерживает динамические
запросы о типе, обратитесь к своей основной библиотеке. Реализован
ли там механизм динамических запросов о типе? Если это так,
задайте операции из $$13.5 как надстройку над этим механизмом.
8. (*2.5) Определите такой строковый класс, в котором нет никакого
динамического контроля, и второй производный от него строковый
класс, который только проводит динамический контроль и обращается
к первому. Укажите плюсы и минусы такого решения по сравнению
с решением,в котором делается выборочный динамический контроль,
сравните с подходом, использующим инварианты, как было предложено
в $$12.2.7.1. Насколько можно совмещать эти подходы?
9. (*4) Определите класс Storable как абстрактный базовый класс с
виртуальными функциями writeout() и readin(). Для простоты
допустим, что для задания нужного адресного пространства достаточно
строки символов. С помощью класса Storable реализуйте
обмен объектами с диском. Проверьте его на объектах нескольких
классов по своему усмотрению.
10.(*4) Определите базовый класс Persistent с операциями save()
и nosave(), который будет проверять, что деструктор создал объект
в определенной памяти. Какие еще полезные операции можно предложить?
Проверьте класс Persistent на нескольких классах по своему выбору.
Является ли класс Persistent узловым классом, конкретным или
абстрактным типом? Аргументируйте ответ.
11.(*3) Составьте только описание класса stack, который реализует
стек с помощью операций create() (создать стек), delete()
(уничтожить стек), push() (записать в стек) и pop() (читать из
стека). Используйте только статические члены. Для привязки и
обозначения стеков определите класс id. Гарантируйте, что
пользователь сможет копировать объекты stack::id, но не сможет
работать с ними иным способом. Сравните это определение стека
с классом stack из $$8.2.
12.(*3) Составьте описание класса stack, который является абстрактным
типом ($$13.3). Предложите две различные реализации для интерфейса,
заданного stack. Напишите небольшую программу, работающую с
этими классами. Сравните это решение с классами, определяющими
стек, из предыдущего упражнения и из $$8.2.
13.(*3) Составьте такое описание класса stack, для которого можно
в динамике менять реализацию. Подсказка: "Всякую задачу можно
решить, введя еще одну косвенность".
14.(*3.5) Определите класс Oper, содержащий идентификатор (некоторого
подходящего типа) и операцию (некоторый указатель на функцию).
Определите класс cat_object, содержащий список объектов Oper и
объект типа void*. Задайте в классе cat_object операции:
add_oper(), которая добавляет объект к списку; remove_oper(id),
которая удаляет из списка объект Oper c идентификатором id;
operator() (id,arg), которая вызывает функцию из объекта Oper c
идентификатором id. Реализуйте с помощью класса cat_object
стек объектов Oper. Напишите небольшую программу, работающую
с этими классами.
15.(*3) Определите шаблон типа Object, служащий базовым классом
для cat_object. С помощью Object реализуйте стек для объектов
класса String. Напишите небольшую программу, использующую этот
шаблон типа.
16.(*3) Определите вариант класса Object под именем Class, в котором
объекты с одинаковым идентификатором имеют общий список операций.
Напишите небольшую программу, использующую этот шаблон типа.
17.(*3) Определите шаблон типа Stack, который задает традиционный
и надежный интерфейс со стеком, реализуемым объектом шаблона
типа Object. Сравните это определение стека с классами, задающими
стек, из предыдущих упражнений. Напишите небольшую программу,
использующую этот шаблон типа.