199
вернулась в главное хранилище памяти. По аналогии с тем, как мы разделили двухшаговый процесс конструирования, можно разделить и двухшаговый процесс уничтожения, напрямую вызывая деструкторы. Однако в отличие от тех выкрутасов, которыми сопровождалось разделение процесса конструирования, с уничтожением дело обстоит очень просто — достаточно вызвать деструктор так, словно это обычная функция класса.
void f() |
|
|
|
{ |
|
|
|
Pool localPool; |
|
|
|
Foo* foo1 = new Foo; |
// Использует оператор new по умолчанию |
||
Foo* foo2 = new(&localPool) Foo; |
// Использует перегрузку |
||
delete foo1; |
// Для оператора new по умолчанию |
||
foo2->~Foo(); |
// Прямой вызов деструктора |
||
}
localPool — большой блок памяти, локальный по отношению к функции. Поскольку он создается в стеке, при завершении f() он выталкивается из стека. Выделение происходит молниеносно, поскольку локальные объекты заполняют пул снизу вверх. Освобождение происходит еще быстрее, поскольку уничтожается сразу весь пул. Единственная проблема заключается в том, что компилятор не будет автоматически вызывать деструкторы объектов, созданных внутри localPool. Вам придется сделать это самостоятельно, используя только что описанную методику.
Кто управляет выделением памяти?
Довольно разговоров о конкретных механизмах; поговорим об архитектуре. Существуют три основные стратегии для определения того, где объект будет находиться в памяти и как занимаемая им память в конечном счете возвратится в систему:
1. Глобальное управление.
2.Управление в классах.
3.Управление под руководством клиента.
Впрочем, это не окончательная классификация: клиентский код может определять, а может и не определять место размещения объектов. Эти решения могут приниматься, а могут и не приниматься объектами классов. Наконец, вся тяжелая работа может выполняться ведущими указателями, а может и не выполняться.
Глобальное управление
По умолчанию объекты создаются глобальным оператором new и уничтожаются глобальным оператором delete. Перегрузка этих операторов позволяет вам реализовать нестандартную схему управления памятью, но это считается дурным тоном.
•Очень трудно объединить раздельно написанные библиотеки, каждая из которых перегружает заданные по умолчанию операторы new и delete.
•Ваши перегрузки влияют не только на ваш код, но и на код, написанный другими (включая библиотеки, для которых нет исходных текстов).
•Все перегрузки, принадлежащие конкретному классу, перегружают ваши глобальные версии. На языке С++ это звучит так, словно вы заказываете чай одновременно с молоком и лимоном. Если вам захочется проделать нечто подобное у себя дома или в офисе — пожалуйста, но я не советую упоминать об этом на семинарах по С++.
•Пользователи могут изменить вашу предположительно глобальную стратегию, перегружая операторы new и delete в конкретных классах. Перегрузка стандартных глобальных операторов дает меньше, чем хотелось бы.
200
Выделение и освобождение памяти в классах
Перегрузка операторов new и delete как функций класса несколько повышает ваш контроль над происходящим. Изменения относятся только к данному классу и его производным классам, так что побочные эффекты обычно оказываются минимальными. Такой вариант работает лучше всего при выделении нестандартной схемы управления памятью в отдельный класс и его последующем подключении средствами множественного наследования. Для некоторых схем управления памятью такая возможность исключается, но это уже трудности архитектора — показать, почему ее не следует реализовывать на базе подключаемых классов.
Если управление памятью реализовано в классе и вы можете создать от него производный класс, деструктор следует сделать виртуальным, чтобы тот же класс мог и исвобождать память. Производные классы не должны перегружать перегруженные версии.
Управление памятью под руководством клиента
Как демонстрируют приведенные выше фрагменты, клиентский код может выбирать, где объект должен находиться в памяти. Обычно это делается с помощью перегруженного оператора new, имеющего дополнительные аргументы помимо size_t. В управлении памятью открываются новые перспективы — управление на уровне отдельных объектов, а не класса в целом. К сожалению, эта стратегия перекладывает на клиента хлопоты, связанные с освобождением памяти. Реализация получается сложной, а модульность — низкой. Например, стоит изменить аргументы нестандартного оператора new, и вам придется вносить изменения во всех местах клиентского кода, где он используется. Пока все перекомпилируется заново, можно погулять на свежем воздухе. Впрочем, несмотря на все проблемы, эта стратегия легко реализуема, очень эффективна и хорошо работает в простых ситуациях.
Объекты классов и производящие функции
Расположение объекта в памяти также может выбираться объектом класса или производящей функцией (или функциями). Возможны разные варианты, от простейших (например, предоставление одной стратегии для всего класса) до выбора стратегии на основании аргументов, переданных производящей функции. При использовании нескольких стратегий вы неизменно придете к стратегии невидимых указателей, рассмотренной в следующем разделе. Более того, эти две концепции прекрасно работают вместе.
Управление памятью с применением ведущих указателей
Похоже, я соврал; в этой главе нам все же придется вернуться к умным указателям. Управление памятью под руководством клиента можно усовершенствовать, инкапсулируя различные стратегии в умных ведущих указателях. Расширение архитектуры с локальными пулами демонстрирует основную идею, которая может быть приспособлена практически для любой схемы с управлением на уровне объектов.
Специализированные ведущие указатели
Простейшая стратегия заключается в создании специализированного класса ведущего указателя или шаблона, который знает о локальном пуле и использует глобальную перегрузку оператора new.
struct Pool { ... }; |
// Как и раньше |
void* operator new(Pool* p); // Выделение из пула |
|
template <class Type> |
|
class PoolMP { |
|
private: |
|
Type* pointee; |
|
PoolMP(const PoolMP<Type>&) {} |
// Копирование не разрешено... |
PoolMP<Type>& operator=(const PoolMP<Type>&) |
|
{ return *this; } |
// ...и присваивание тоже |
public: |
|
201
PoolMP(Pool* p) : pointee(new(p) Type) {} ~PoolMP() { pointee->~Type(); }
Type* operator->() const { return pointee; }
};
При желании клиент может использовать PoolMP для выделения и освобождения памяти в локальном пуле. Деструктор ведущего указателя вызывает деструктор указываемого объекта, но не освобождает память. Поскольку ведущий указатель не следит за исходным пулом, копирование и присваивание поддерживать не удастся, так как ведущий указатель понятия не имеет, в каком пуле создавать новые копии. Если не считать этих недостатков, перед нами фактически простейший указатель, не отягощенный никакими издержками.
На это можно возразить, что копирование и присваивание все же следует поддерживать, но с использование операторов new и delete по умолчанию. В этом случае конструктор копий и оператор = работают так же, как и для обычного ведущего указателя.
Обратные указатели на пул
Чтобы поддерживать копирование и присваивание в пуле, можно запоминать адрес пула.
template <class Type> class PoolMP { private:
Type* pointee; Pool* pool;
public:
PoolMP(Pool* p) : pointee(new(p) Type), pool(p) {} ~PoolMP() { pointee->Type::~Type(); }
PoolMP(const PoolMP<Type>& pmp) : pointee(new(pool) Type(*pointee)) {} PoolMP<Type>& operator=(const PoolMP<Type>& pmp)
{
if (this == &pmp) return *this; delete pointee;
pointee = new(pool) Type(*pointee); return *this;
}
Type* operator->() const { return pointee; }
};
Это обойдется вам в четыре лишних байта памяти, но не потребует лишних тактов процессора по сравнению с использованием обычных ведущих указателей.
Сосуществование с обычными ведущими указателями
Предложенное решение отнюдь не идеально. Интерфейс PoolMP открывает многое из того, о чем следовало бы знать только классам. Более того, если вам захочется совместно работать с объектами из пула и объектами, размещенными другим способом (например, с помощью стандартного механизма), начинаются настоящие трудности. Ценой добавления v-таблицы мы сможем значительно лучше инкапсулировать отличия в стратегиях управления памятью.
template <class Type> class MP {
protected:
MP(const MP<Type>&) {} // Копирование не разрешено MP<Type>& operator=(const MP<Type>&)
{ return *this; } // Присваивание – тоже
MP() {} // Используется только производными классами
202
public:
virtual ~MP() {} // Освобождение выполняется производными классами virtual Type* operator->() const = 0;
};
template <class Type>
class DefaultMP : public MP<Type> { private:
Type* pointee; public:
DefaultMP() : pointee(new Type) {} DefaultMP(const DefaultMP<Type>& dmp)
: pointee(new Type(*dmp.pointee)) {} virtual ~DefaultMP() { delete pointee; }
DefaultMP<Type>& operator=(const DefaultMP<Type>& dmp)
{
if (this == &dmp) return *this; delete pointee;
pointee = new Type(*dmp.pointee); return *this;
}
virtual Type* operator->() const { return pointee; }
};
template <class Type>
class LocalPoolMP : public MP<Type> { private:
Type* pointee; Pool* pool;
public: LocalPoolMP(Pool* p)
:pointee(new(p) Type), pool(p) [] LocalPoolMP(const LocalPoolMP<Type>& lpmp)
:pointee(new(lpmp.pool) Type(*lpmp.pointee)), pool(lpmp.pool) {} virtual ~LocalPoolMP() { pointee->Type::~Type(); }
LocalPoolMP<Type>& operator=(const LocalPoolMP<Type>& lpmp)
{
if (this == &lpmp) return *this; pointee->Type::~Type();
pointee = new(pool) Type(*lpmp.pointee); return *this;
}
virtual Type* operator->() const { return pointee; }
};
Теперь DefaultMP и LocalPoolMP можно использовать совместно — достаточно сообщить клиенту, что они принадлежат к типу MP<Type>&. Копирование и присваивание поддерживается для тех классов, которые взаимодействуют с производными классами, но запрещено для тех, которые знают только о базовом классе. В приведенном коде есть одна тонкость: операторная функция
LocalPoolMP::operator= всегда использует new(pool) вместо new(lpmp.pool). Это повышает
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 (например, с передачей размера экземпляра).