Управление памятью с применением ведущих указателей

Похоже, я соврал; в этой главе нам все же придется вернуться к умным указателям. Управление памятью под руководством клиента можно усовершенствовать, инкапсулируя различные стратегии в умных ведущих указателях. Расширение архитектуры с локальными пулами демонстрирует основную идею, которая может быть приспособлена практически для любой схемы с управлением на уровне объектов.

Специализированные ведущие указатели

Простейшая стратегия заключается в создании специализированного класса ведущего указателя или шаблона, который знает о локальном пуле и использует глобальную перегрузку оператора 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:

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() {} // Используется только производными классами

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). Это повышает безопасность в тех ситуациях, когда два ведущих указателя поступают из разных областей действия и разных пулов.

Невидимые указатели

Раз уж мы «заплатили вступительный взнос» и создали иерархию классов ведущих указателей, почему бы не пойти дальше и не сделать эти указатели невидимыми? Вместо применения шаблона нам придется реализовать отдельный класс указателя для каждого класса указываемого объекта, но это не слишком большая цена за получаемую гибкость.

// В файле 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*). Остальные пользователи полученного невидимого указателя понятия не имеют, находится их рабочий объект в пуле или нет.

Стековые оболочки

Чтобы добиться максимальной инкапсуляции, следует внести в описаннуюархитектуру следующие изменения:

1.   Сделать Pool чисто абстрактным базовым классом с инкапсулированными производными классами, производящими функциями и т.д.

2.   Предоставить функцию static Foo::makePool(). Функция make(Pool*) будет работать и

для других разновидностей Pool, но makePool() позволяет Foo выбрать производящую

функцию Pool, оптимальную для хранения Foo (например, с передачей размера экземпляра).

3.   Переработать старый шаблон 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> pool(Foo::makePool());

MP<Foo> foo(Foo::make(pool));

foo->MemberOfFoo(); // Использует операторную функцию operator->()

g(foo); // Использует операторную функцию operator Type*()

// Выход из области действия - удаляется сначала foo, затем pool

}