Мы перечислили виды классов, из которых можно создать библиотеки,нацеленные на проектирование и повторное использование прикладныхпрограмм. Они предоставляют определенные "строительные блоки" иобъясняют как из них строить. Разработчик прикладного обеспечения создаеткаркас, в который должны вписаться универсальные строительные блоки. Задачапроектирования прикладных программ может иметь иное, более обязывающеерешение: написать программу, которая сама будет создавать общий каркасобласти приложения. Разработчик прикладного обеспеченияв качестве строительных блоков будет встраивать в этот каркасприкладные программы. Классы, которые образуют каркас областиприложения, имеют настолько обширный интерфейс, что их трудноназвать типами в обычном смысле слова. Они приближаются к томупределу, когда становятся чисто прикладными классами, но при этомв них фактически есть только описания, а все действия задаютсяфункциями, написанными прикладными программистами. Для примера рассмотрим фильтр, т.е. программу, которая можетвыполнять следующие действия: читать входной поток, производитьнад ним некоторые операции, выдавать выходной поток и определятьконечный результат. Примитивный каркас для фильтра будет состоятьиз определения множества операций, которые должен реализоватьприкладной программист: 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]; } //... }; Если пользователь не будет заносить в контейнер вместо указателей наобъекты сами объекты типа 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; } } };