straustrup2 (852740), страница 98
Текст из файла (страница 98)
Но как быть, если действительно требуетсяуничтожить размещенный в свободной памяти объект, который не был удален? Заметим, что длястатических и автоматических объектов такой вопрос не встает, - деструкторы для них неявновызываются всегда. Далее, уничтожение объекта "во время сборки мусора" по сути является операциейс непредсказуемым результатом. Она может совершиться в любое время между последнимиспользованием объекта и "концом программы", а значит, в каком состоянии будет программа в этотмомент неизвестно. Здесь использованы кавычки, потому что трудно точно определить, что такое конецпрограммы.
(прим. перев.)Трудно правильно запрограммировать такие операции и они не так полезны, как кажется.Задачу уничтожения объектов, если время этой операции точно не задано, можно решить с помощьюпрограммы обслуживания заявок на уничтожение.
Назовем ее сервером заявок. Если объектнеобходимо уничтожить в конце программы, то надо записать в глобальный ассоциативный массив егоадрес и указатель на функцию "очистки". Если объект удален явной операцией, заявка аннулируется.При уничтожении самого сервера (в конце программы) вызываются функции очистки для всехоставшихся заявок. Это решение подходит и для сборки мусора, поскольку мы рассматриваем ее какмоделирование бесконечной памяти. Для сборщика мусора нужно выбрать одно из двух решений: либоудалять объект, когда единственной оставшейся ссылкой на него будет ссылка, находящаяся в массивесамого сервера, либо (стандартное решение) не удалять объект до конца программы, поскольку всетаки ссылка на него есть.Сервер заявок можно реализовать как ассоциативный массив ($$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;362Бьерн Страуструп.Язык программирования С++Класс, постоянно обращающийся к серверу, может выглядеть так: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*.13.10.2 Контейнеры и удалениеДопустим, что у нас нет бесконечной памяти и сборщика мусора.
На какие средства управленияпамятью может рассчитывать создатель контейнера, например, класса 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;363Бьерн Страуструп.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){// проверка sp = 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;// предотвращает удаление s364Бьерн Страуструп.Язык программирования С++// все оставшиеся указатели// автоматически удаляются при выходе}Естественно, такое решение годится только для контейнеров, в которых не содержатся копии объектов,а для класса 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){// проверка sp = 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];365Бьерн Страуструп.Язык программирования С++}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; }}};13.10.3 Функции размещения и освобожденияВо всех приведенных примерах память рассматривалась как нечто данное.
Однако, обычная функцияобщего назначения для распределения свободной памяти оказывается до удивления менееэффективной, чем функция размещения специального назначения. Вырожденным случаем такихфункций можно считать приведенный пример с размещением в "бесконечной" памяти и с пустойфункцией освобождения. В библиотеке могут быть более содержательные функции размещения, ибывает, что с их помощью удается удвоить скорость выполнения программы. Но прежде, чем пытатьсяс их помощью оптимизировать программу, запустите для нее профилировщик, чтобы выявитьнакладные расходы, связанные с выделением памяти.В разделах $$5.5.6 и $$6.7 было показано как с помощью определения функций X::operator new() иX::operator delete() можно использовать функцию размещения для объектов класса X.
Здесь естьопределенная трудность. Для двух классов X и Y функции размещения могут быть настолько сходными,что желательно иметь одну такую функцию. Иными словами, желательно иметь в библиотеке такойкласс, который предоставляет функции размещения и освобождения, пригодные для размещенияобъектов данного класса. Если такой класс есть, то функции размещения и освобождения для данногокласса получаются за счет привязки к нему общих функций размещения и освобождения:class X {366Бьерн Страуструп.Язык программирования С++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() без параметра.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
