class PFoo { Умный указатель на Foo private:

Foo* foo; public:

FunctionThatEnumeratesPointersInFoo();

Теперь мы начинаем с одного умного указателя, PFoo, и рекурсивно находим другой, PBar. Каждый из этих умных указателей разбирается в особенностях строения объекта, на который он ссылается. В этом они превзошли умные указатели, поэтому я называю их осведомленнгми (ingenious), хотя циник, вероятно, назвал бы их нерассуждающими.

Перебор графа объектов

В дальнейшем мы воспользуемся методикой виртуальных функций из приведенного выше списка, хотя материал с таким же успехом применим и к объектам классов. Перечисление реализуется двумя основными способами: с применением рекурсивных функций и функторов, а также с применением итераторов.

Рекурсивные функции и функторы

Первая естественная реакция: организовать механизм косвенного вызова, создать функцию или функтор, вызываемые для каждого доступного объекта, и подождать, пока закончится рекурсивный перебор.

class Functor { Функция обратного вызова public:

virtual void App1y(MotherOfAllClasses*) = 0;

class MotherOfAllClasses { public:

Применить fn к каждому доступному объекту virtual void EachObject(Functor& fn);

Функция EachObject() вызывает fn.Apply(this), а затем вызывает EachObject() для каждого внедренного объекта или объекта, на который указывает переменная класса. Кроме того, EachObject() вызывает Base::EachObject() для каждого базового класса, таким образом члены базового класса тоже включаются в перечисление. В зависимости от алгоритма в MotherOfAllClasses можно включить бит признака, показывающий, что объект был рассмотрен ранее. Впрочем, как мы вскоре убедимся, иногда без этого можно обойтись.

Итераторы

Более удачное решение - организовать возвращение объектом итератора для всех внедренных объектов (включая базовые классы), в том числе и тех, на которые непосредственно ссылаются его переменные.

class MOAOIterator { "MotherOfAllObjectsIterator" public:

virtual bool More() = 0;

virtual MotherOfAllObjects* Next() = 0;

class MotherOfAllObjects { public:

virtual MOAOIterator* EachObject();

Конечно, на этот раз потребуется более хитроумный код, чем в варианте с виртуальными функциями из последнего раздела. Тем не менее, методика «итераторы всюду» обладает одним громадным преимуществом: она позволяет выполнять действия последовательно. Вариант с рекурсивными функциями не позволяет каждую миллисекунду или около того делать передышку и давать поработать другому коду. При использовании итераторов, если соблюдать осторожность, это не проблема. Далее мы будем использовать именно этот вариант.

Сборка мусора по алгоритму Бейкера

Наверное, вам хочется знать, зачем нужен алгоритм Бейкера, не правда ли? В предыдущей главе я выдал его за алгоритм уплотнения, но что толку уплотнять память, если для этого приходится жертвовать 50 процентами ее общего объема? Теперь мы узнаем настоящую прелесть алгоритма Бейкера - его применение в архитектурах сборки мусора.

На данный момент мы не будем беспокоиться об объектах, доступных извне, и сосредоточим внимание на периметре стековых переменных.

Поскольку на этот раз мы занимаемся сборкой мусора, нет причин полагаться во всем на подсчет ссылок. Тем не менее, подсчет ссылок продолжает играть важную роль: он применяется для подсчета дескрипторов в стеке, ссылающихся на конкретный ведущий указатель. Ведущий указатель, у которого счетчик ссылок больше 0, непосредственно доступен из стека, а следовательно, входит в периметр. Мы воспользуемся сильными дескрипторами для стековых переменных и слабыми дескрипторами для ссылок из одного объекта на другой через переменные класса. VoidPtr и другие структуры данных из предыдущей главы остаются без изменений, за одним исключением: VoidPtr::Re1ease() не удаляет ведущий указатель при обнулении счетчика. Запомните: нулевой счетчик ссылок означает не то, что объект вообще недоступен, а лишь то, что он недоступен непосредственно из стека.

Шаблон слабого дескриптора

Слабый дескриптор устроен просто. template <c1ass Type> class WH {

friend class Hand1e<Type>; private:

BMP<Type>* pointer;

WH() : pointer(new BMP<Type> (new(object space) Type)) {}; BMP<Type>& operator->() { return *pointer; }

Он используется в переменных классов, которые ссылаются на другие объекты. class Foo { private:

WH<Bar> bar; При конструировании создает Bar + MP<Bar>

Шаблон сильного дескриптора

Шаблон сильного дескриптора идентичен шаблону слабого, за исключением того, что он поддерживает счетчик ссылок для указателя.

template <c1ass Type>

class SH {

private:

BMP<Type>* pointer; public:

SH() : pointer(new BMP<Type>(new Type)) { pointer->Grab(); } SH(const SH<Type>& h) : pointer(h.pointer) { pointer->Grab(); }

SH(const WH<Type>& h) : pointer(h.pointer) { pointer->Grab(); } operator WH<Type>() { return WH<Type>(pointer); } SH<Type>& operator=(const SH<Type>& h)

if (this == &h) return *this;

if (pointer == h.pointer) return *this;

pointer->Re1ease();

h.pointer->Grab();

return *this;

BMP<Type>& operator->() { return *pointer; }

Шаблон используется для обычных переменных (а не для переменных класса), ссылающихся на объекты. Благодаря конструктору, принимающему H<Type>, и операторной функции operator H<Type>() он также может использоваться в операциях присваивания с участием переменных классов, то есть слабых дескрипторов.

class Bar { private:

WH<Foo> foo; public:

void f();

void Bar::f()

SH<Foo> f; Эквивалентно Foo* f = new Foo;

f = foo; Использует operator=(SH<Type>(foo));

foo = f; Использует operator WH<Type>(f);

Итераторы ведущих указателей

Помните VoidPtrIterator? VoidPtrPool возвращает один итератор для перебора всех указателей с ненулевыми счетчиками ссылок. Все остается без изменений, однако счетчик ссылок теперь интерпретируется по-другому. Раньше ненулевой счетчик ссылок означал, что объект не следует уничтожать. Теперь он имеет более узкое значение: объект доступен непосредственно из стека. Все эти объекты сохраняются, поскольку они находятся на периметре, но мы также сохраним объекты с нулевыми счетчиками ссылок, если они доступны косвенно.

Для объектов внутри периметра мы должны перебрать дескрипторы каждого объекта периметра, а затем рекурсивно двигаться внутрь до тех пор, пока не будут перебраны все доступные объекты. Для этого нам придется анализировать объекты одним из описанных выше способов. В данном примере будет использовано сочетание виртуальных функций/итераторов. Для этой цели можно слегка переработать старый интерфейс VoidPtrIterator.

class VoidPtrIterator { protected:

VoidPtrIterator() {} public:

virtual bool More() = 0;

virtual VoidPtr* Next() = 0;

Теперь пул должен поддерживать два типа итераторов. Один итератор перебирает указатели, находящиеся на периметре (то есть имеющие ненулевые счетчики ссылок). Второй - указатели на