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*. К сожалению, разные возвращаемые типы не обеспечивают уникальности сигнатур, поэтому при попытке объявить два оператора -> компилятор от души посмеется. Программисту придется заранее вызвать функцию, которая осуществляет переход от одного представления к другому.

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

Грани и другие мудрые указатели

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

Интерфейсные указатели

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

• Класс и его друзья видят один интерфейс, включающий всех членов класса и всех защищенных и открытых членов его базовых классов.

• Производные классы видят только защищенных и открытых членов класса и его базовых классов.

• Все остальные клиенты видят только открытых членов класса и его базовых классов.

• Если указатель на объект преобразуется к указателю на его базовый класс, интерфейс ограничивается только открытыми членами базового класса.

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

Дублирование интерфейса

Давайте посмотрим, можно ли обобщить эту концепцию с помощью еще более умных (назовем их «мудрыми») указателей (smarter pointers). Для начала нам придется на некоторое время покинуть своего старого друга, оператор ->. Одно из ограничений оператора -> заключается в следующем: чтобы использовать указатель, клиент также должен знать все об интерфейсе указываемого объекта.

class Foo {

Интерфейсная часть, которую бы вам хотелось спрятать подальше

Ptr<Foo> pf(new Foo);

Хммм. Чтобы клиент мог пользоваться указателем, нам придется рассказать ему все что только можно об указываемом объекте Foo. Не хотелось бы. Ниже показан альтернативный вариант. Терпение - все не так страшно, как кажется на первый взгляд.

class Foo { friend class Pfoo; protected:

Foo();

public: