C++: библиотека программиста

 
203 
безопасность в тех ситуациях, когда два ведущих указателя поступают из разных областей действия и 
разных пулов. 
Невидимые указатели 
Раз уж мы «заплатили вступительный взнос» и создали иерархию классов ведущих указателей, почему 
бы не пойти дальше и не сделать эти указатели невидимыми? Вместо применения шаблона нам 
придется реализовать отдельный класс указателя для каждого класса указываемого объекта, но это не 
слишком большая цена за получаемую гибкость. 
// В файле foo.h 
class Foo { 
public: 
static Foo* make(); 
// Использует выделение по умолчанию 
static Foo* make(Pool*); // Использует пул 
virtual ~Foo() {} 
// 
Далее следуют чисто виртуальные функции 
}; 
// В файле foo.cpp 
class PoolFoo : public Foo { 
private: 
Foo* 
foo; 
Pool* 
pool; 
public: 
PoolFoo(Foo* f, Pool* p) : foo(f), pool(p) {} 
virtual ~PoolFoo() { foo->~Foo(); } 
// 
Переопределения функций класса, делегирующие к foo 
}; 
class PFoo : public Foo { 
// Обычный невидимый указатель 
}; 
class ConcreteFoo : public Foo { ... }; 
Foo* Foo::make() 
{ 
return new PFoo(new ConcreteFoo); 
} 
Foo* Foo::make(Pool* p) 
{ 
return new PoolFoo(new(p) ConcreteFoo, p); 
} 
Такой вариант намного «чище» для клиента. Единственное место, в котором клиентский код должен 
знать что-то о пулах, — создание объекта функцией 
make(Pool*)
. Остальные пользователи 
полученного невидимого указателя понятия не имеют, находится их рабочий объект в пуле или нет. 
Стековые оболочки 
Чтобы добиться максимальной инкапсуляции, следует внести в описанную архитектуру следующие 
изменения: 
• 
Сделать 
Pool
чисто абстрактным базовым классом с инкапсулированными производными 
классами, производящими функциями и т.д. 
• 
Предоставить функцию 
static Foo::makePool()
. Функция 
make(Pool*)
будет работать и 
для других разновидностей 
Pool
, но 
makePool()
позволяет 
Foo
выбрать производящую 
функцию 
Pool
, оптимальную для хранения 
Foo
(например, с передачей размера экземпляра). 

---

 204 
• 
Переработать старый шаблон 
MP
из предыдущих глав (с операторной функцией 
operator 
Type*()
), чтобы при выходе из пула и указателей за пределы области действия все 
необходимое автоматически уничтожалось. 
Ниже показан примерный вид полученного интерфейса, с фрагментом клиентского кода и без 
виртуального оператора 
=
. 
// В файле foo.h 
// Подключить объявление чисто абстрактного базового класса 
#include “pool.h” 
class Foo { 
private: 
Foo(const 
Foo&) 
{} 
Foo& operator=(const Foo&) { return *this; } 
public: 
static Pool* makePool(); // Создать пул, оптимизированный для Foo 
static Foo* make(); 
// Не использует пул 
static Foo* make(Pool*); // Использует пул 
// 
И т.д. 
}; 
// Клиентский код 
void g(Foo*); 
void f() 
{ 
MP
pool(Foo::makePool()); 
MP 
foo(Foo::make(pool)); 
foo->MemberOfFoo(); // 
Использует операторную функцию operator->() 
g(foo); 
// 
Использует операторную функцию operator Type*() 
// 
Выход из области действия – удаляется сначала foo, затем pool 
} 
Перспективы 
Глава заканчивается хорошо — умной, эффективной инкапсуляцией очень сложной проблемы дизайна. 
Единственным уязвимым местом является вызов функции 
g()
, которая должна пообещать не 
сохранять долговременный указатель на свой аргумент. Впрочем, подобный анализ необходимо 
проводить для любой архитектуры, в которой используются временные пулы; в нашем случае ключом 
является инкапсуляция. 
На время забудьте о пулах, временных или иных, и вы увидите разнообразные стратегии применения 
ведущих указателей для поддержки и инкапсуляции управления памятью в С++. 

---

Основы 
управления 
памятью 
В этой главе описаны некоторые простые стратегии управления памятью. Если вы пропустили 
предыдущую главу, вернитесь и прочитайте ее. Весь материал, изложенный в этой и следующих