template <c1ass Type>

inline Type* MP<Type>::operator->() const

return t;

Дескрипторы в C++

Итак, после небольшого подогрева умные указатели превратились в ведущие. Теперь в нашем вареве появляется еще один ингредиент - дескрипторы (handles) C++. Не путайте этот термин с дескрипторами, используемыми в операционных системах Macintosh и Windows. Некоторое сходство существует, но идиома дескрипторов C++ имеет собственную уникальную семантику и набор правил.

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

template <c1ass Type>

class H {

private:

MP<Type>& ptr; Ссылка на ведущий указатель public:

H() : ptr(*(new MP<Type>)) {} См. Ниже

H(MP<Type>& mp) : ptr(mp) {}

MP<Type>& operator->() const { return ptr; }

Безаргументный конструктор Н создает новый ведущий указатель. Этот ведущий указатель, в свою очередь, создает указываемый объект. Существует второй конструктор, который получает ведущий указатель и инициализирует им переменную ptr . Конструктор копий и оператор = по умолчанию годятся, поскольку любому ведущему указателю может соответствовать несколько дескрипторов. Работа оператора -> основана на рекурсивном алгоритме, используемом компилятором: оператор -> дескриптора возвращает ведущий указатель; затем оператор -> ведущего указателя возвращает указатель Type* который является одним из базовых типов компилятора.

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

Что же получается?

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

Подсчет объектов

Допустим, вы хотите следить за количеством созданных или находящихся в памяти объектов некоторого класса. Одно из возможных решений - хранить эти сведения в статических переменных самого класса.

class CountedStuff { private:

static int current; public:

CountedStuff() { current++; }

CountedStuff(const CuntedStuff&) { current++; } CountedStuff& operator=(const CountedStuff&)

{} Не менять счетчик для присваивания ~CountedStuff() { current--; }

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

template <c1ass Type> class CMP { private:

static int current;

Type* ptr; public:

CMP() : ptr(new Type) { current++; }

CMP(const CMP<Type>& cmp) : ptr(new Type(*(mp.t))) { current++; } CMP<Type>& operator=(const CMP<Type>& cmp)

if (this != &cmp) { delete ptr;

ptr = new Type(*(cmp.ptr));

return *this;

~CMP() { delete ptr; current--; }

Type* operator->() const { return ptr; }

Static int Current() { return current; }

Теперь ведущий указатель выполняет все подсчеты за вас. Он не требует внесения изменений в класс указываемого объекта. Этот шаблон может использоваться для любого класса при условии, что вам удастся втиснуть ведущие указатели между клиентом и указываемым объектом. Даже если вы не возражаете против модификации исходного класса указываемого объекта, обеспечить такой уровень модульности без ведущих указателей было бы крайне сложно (например, если бы вы попытались действовать через базовый класс, то в результате получили бы одну статическую переменную current на все производные классы).

Этот пример тривиален, но даже он демонстрирует важный принцип программирования на C++, справедливость которого со временем становится очевидной: пользуйтесь умными указателями, даже если сначала кажется, что они не нужны. Если программа написана для умных указателей, все изменения вносятся легко и быстро. Если же вам придется переделывать готовую программу и заменять все операторы * умными указателями, приготовьтесь к ночным бдениям.

В главе 1 4 вариации на тему подсчета будут использованы для реализации простой, но в то же время мощной схемы управления памятью - сборки мусора с подсчетом ссылок.

Указатели только для чтения

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

template <c1ass Type> class ROMP { private:

Type* t; public:

ROMP(); Создает указываемый объект

ROMP(const ROMP<Type>&); Копирует указываемый объект ~ROMP(); Удаляет указываемый объект

ROMP<Type>& operator=(const ROMP<Type>&); const Type* operator->() const;

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

Указатели для чтения/записи

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

Это было бы легко сделать при наличии двух перегруженных версий оператора ->, одна из которых возвращает Foo*, а другая - const Foo*. К сожалению, разные возвращаемые типы не обеспечивают уникальности сигнатур, поэтому при попытке объявить два оператора -> компилятор от души посмеется. Программисту придется заранее вызвать функцию, которая осуществляет переход от одного представления к другому.

Одно из возможных применений этой схемы - распределенные объекты. Если копии объекта не обновляются локальными клиентами, они могут быть разбросаны по всей сети. Совсем другое дело - координация обновлений нескольких экземпляров. Можно установить правило, согласно которому допускается существование любого количества копий только для чтения, но лишь одна главная копия. Чтобы обновить объект, необходимо предварительно получить главную копию у ее текущего владельца. Конечно, приходится учитывать многие нюансы (в частности, процедуру смены владельца главной копии), однако правильное применение ведущих указателей позволяет реализовать эту концепцию на удивление просто и незаметно для клиентов.