12.1.1. Класс shared_ptr

Подобно векторам, интеллектуальные указатели являются шаблонами (см. раздел 3.3). Поэтому при создании интеллектуального указателя следует предоставить дополнительную информацию — в данном случае тип, на который способен указывать указатель. Подобно векторам, этот тип указывают в угловых скобках, следующих за именем типа определяемого интеллектуального указателя:

shared_ptr<string> p1;    // shared_ptr может указывать на строку

shared_ptr<list<int>> p2; // shared_ptr может указывать на

                          // список целых чисел

Инициализированный по умолчанию интеллектуальный указатель хранит нулевой указатель (см. раздел 2.3.2). Дополнительные способы инициализации интеллектуального указателя рассматриваются в разделе 12.1.3.

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

// если указатель p1 не нулевой и не указывает на пустую строку

if (p1 && p1->empty())

 *p1 = "hi"; // обратиться к значению p1, чтобы присвоить ему

             // новое значение строки

Список общих функций указателей shared_ptr и unique_ptr приведен в табл. 12.1. Функции, специфические для указателя shared_ptr, перечислены в табл. 12.2.

Таблица 12.1. Функции, общие для указателей shared_ptr и unique_ptr

Таблица 12.2. Функции, специфические для указателя shared_ptr

Функция make_shared()

Наиболее безопасный способ резервирования и использования динамической памяти подразумевает вызов библиотечной функции make_shared(). Она резервирует и инициализирует объект в динамической памяти, возвращая указатель типа shared_ptr на этот объект. Как и типы интеллектуальных указателей, функция make_shared() определена в заголовке memory.

При вызове функции make_shared() следует указать тип создаваемого объекта. Это подобно использованию шаблона класса — за именем функции следует указание типа в угловых скобках:

// указатель shared_ptr на объект типа int со значением 42

shared_ptr<int> p3 = make_shared<int>(42);

// р4 указывает на строку со значением '9999999999'

shared_ptr<string> р4 = make_shared<string>(10, '9');

// р5 указывает на объект типа int со значением по

// умолчанию (p. 3.3.1) 0

shared_ptr<int> р5 = make_shared<int>();

Подобно функции-члену emplace() последовательного контейнера (см. раздел 9.3.1), функция make_shared() использует свои аргументы для создания объекта заданного типа. Например, при вызове функции make_shared<string>() следует передать аргумент (аргументы), соответствующий одному из конструкторов типа string. Вызову функции make_shared<int>() можно передать любое значение, которое можно использовать для инициализации переменной типа int, и т.д. Если не передать аргументы, то объект инициализируется значением по умолчанию (см. раздел 3.3.1).

Для облегчения определения объекта, содержащего результат вызова функции make_shared(), обычно используют ключевое слово auto (см. раздел 2.5.2):

// p6 указывает на динамически созданный пустой вектор vector<string>

auto p6 = make_shared<vector<string>>();

Копирование и присвоение указателей shared_ptr

При копировании и присвоении указателей shared_ptr каждый из них отслеживает количество других указателей shared_ptr на тот же объект:

auto p = make_shared<int>(42); // объект, на который указывает p

                               // имеет только одного владельца

auto q(p); // p и q указывают на тот же объект

// объект, на который указывают p и q, имеет двух владельцев

С указателем shared_ptr связан счетчик, обычно называемый счетчиком ссылок (reference count). При копировании указателя shared_ptr значение счетчика увеличивается. Например, значение связанного с указателем shared_ptr счетчика увеличивается, когда он используется для инициализации другого указателя shared_ptr, а также при использовании его в качестве правого операнда присвоения, или при передаче его функции (см. раздел 6.2.1), или при возвращении из функции по значению (см. раздел 6.3.2). Значение счетчика увеличивается при присвоении нового значения указателю shared_ptr, а когда он удаляется или когда локальный указатель shared_ptr выходит из области видимости (см. раздел 6.1.1), значение счетчика уменьшается.

Как только счетчик указателя shared_ptr достигает нуля, он автоматически освобождает объект, на который указывает:

auto r = make_shared<int>(42); // объект int, на который указывает r,

                               // имеет одного владельца

r = q; // присвоение r переводит этот указатель на другой адрес

// приращение счетчика владельцев объекта, на который указывает q

// уменьшение счетчика владельцев объекта, на который указывает r

// объект, на который указывал r, не имеет более владельцев;

// он освобождается автоматически

Здесь резервируется переменная типа int, а ее адрес сохраняется в указателе r. Затем указателю r присваивается новое значение. В данном случае r — единственный указатель типа shared_ptr, указывающий на этот объект. В результате присвоения r = q переменная int автоматически освобождается.

Будет ли использован счетчик или другая структура данных для отслеживания количества указателей на совместно используемый объект, зависит от реализации компилятора. Главное то, что класс отслеживает количество указателей shared_ptr на тот же объект и автоматически освобождает его в подходящий момент.

Указатель shared_ptr автоматически удаляет свои объекты…

Когда последний указатель shared_ptr на объект удаляется, его класс автоматически удаляет объект, на который он указывает. Для этого используется другая специальная функция-член — деструктор (destructor), аналогичная конструкторам, которые есть у каждого класса. Подобно тому, как конструктор контролирует инициализацию, деструктор контролирует происходящее при удалении объектов этого типа.

Деструкторы обычно освобождают ресурсы, зарезервированные объектом. Например, конструкторы класса string (как и другие его члены) резервируют память для содержания составляющих ее символов. Деструктор класса string освобождает эту память. Точно так же некоторые функции класса vector резервируют память для хранения элементов вектора. Деструктор класса vector удаляет эти элементы и освобождает используемую ими память.

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

…и автоматически освобождает их память

Тот факт, что класс shared_ptr автоматически освобождает динамические объекты, когда они больше не нужны, существенно облегчает использование динамической памяти. Рассмотрим, например, функцию, которая возвращает указатель shared_ptr на динамически созданный объект типа Foo, который может быть инициализирован аргументом типа Т:

// функция factory() возвращает указатель shared_ptr на динамически

// созданный объект

shared_ptr<Foo> factory(Т arg) {

 // обработать аргумент соответствующим образом

 // shared_ptr позаботится об освобождении этой памяти

 return make_shared<Foo>(arg);

}

Функция factory() возвращает указатель shared_ptr, гарантирующий удаление созданного ею объекта в подходящий момент. Например, следующая функция сохраняет указатель shared_ptr, возвращенный функцией factory(), в локальной переменной:

void use_factory(Т arg) {

 shared_ptr<Foo> p = factory(arg);

 // использует p

} // p выходит из области видимости; память, на которую он указывал,

  // освобождается автоматически

Поскольку указатель p является локальным для функции use_factory(), он удаляется по ее завершении (см. раздел 6.1.1). Когда указатель p удаляется, осуществляется декремент его счетчика ссылок и проверка. В данном случае p — единственный указатель на объект в памяти, возвращенный функцией factory(). Поскольку указатель p выходит из области видимости, объект, на который он указывает, удаляется, а память, в которой он располагался, освобождается.

Память не будет освобождена, если на нее будет указывать любой другой указатель типа shared_ptr:

shared_ptr<Foo> use_factory(Т arg) {

 shared_ptr<Foo> p = factory(arg);

 // использует p

 return p; // при возвращении p счетчик ссылок увеличивается

} // p выходит из области видимости; память, на которую он указывал,

  // не освобождается

В этой версии функции use_factory() оператор return возвращает вызывающей стороне (см. раздел 6.3.2) копию указателя p. Копирование указателя shared_ptr добавляет единицу к счетчику ссылок этого объекта. Теперь, когда указатель p удаляется, останется другой владелец области памяти, на которую указывал указатель p. Класс shared_ptr гарантирует, что пока есть хоть один указатель shared_ptr на данную область памяти, она не будет освобождена.

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

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

Классы, ресурсы которых имеют динамическую продолжительность существования

Обычно динамическую память используют в следующих случаях.

1. Неизвестно необходимое количество объектов.

2. Неизвестен точный тип необходимых объектов.

3. Нельзя разрешать совместное использование данных несколькими объектами.

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

Использованные до сих пор классы резервировали ресурсы, которые существовали, только пока существовал объект. Например, каждому вектору принадлежат его собственные элементы. При копировании вектора элементы исходного вектора копировались в независимые элементы другого:

vector<string> v1; // пустой вектор

{ // новая область видимости

 vector<string> v2 = {"a", "an", "the"};

 v1 = v2; // копирует элементы из v2 в v1

} // v2 удаляется, что удаляет элементы v2

  // v1 содержит три элемента, являющихся копиями элементов v2

Элементы вектора существуют, только пока существует сам вектор. Когда вектор удаляется, удаляются и его элементы.

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

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

Blob<string> b1; // пустой Blob

{ // новая область видимости

 Blob<string> b2 = {"a", "an", "the"};

 b1 = b2; // b1 и b2 совместно используют те же элементы

} // b2 удаляется, но элементы b2 нет

  // b1 указывает на элементы, первоначально созданные в b2

В этом примере объекты b1 и b2 совместно используют те же элементы. Когда объект b2 выходит из области видимости, эти элементы должны остаться, поскольку объект b1 все еще использует их.

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

Определение класса StrBlob

В конечном счете класс Blob будет реализован как шаблон, но это только в разделе 16.1.2, а пока определим его версию, способную манипулировать только строками. Поэтому назовем данную версию этого класса StrBlob.

Простейший способ реализации нового типа коллекции подразумевает использование одного из библиотечных контейнеров. Это позволит библиотечному типу управлять собственно хранением элементов. В данном случае для хранения элементов будет использован класс vector.

Однако сам вектор не может храниться непосредственно в объекте Blob. Члены объекта удаляются при удалении самого объекта. Предположим, например, что объекты b1 и b2 класса Blob совместно используют тот же вектор. Если бы вектор хранился в одном из этих объектов, скажем в b2, то, как только объект b2 выйдет из области видимости, элементы вектора перестанут существовать. Чтобы гарантировать продолжение существования элементов, будем хранить вектор в динамической памяти.

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

Осталось решить, какие функции будет предоставлять создаваемый класс. Реализуем пока небольшое подмножество функций вектора. Изменим также функции обращения к элементам (включая front() и back()): в данном классе при попытке доступа к не существующим элементам они будут передавать исключения.

У класса будет стандартный конструктор и конструктор с параметром типа initializer_list<string> (см. раздел 6.2.6). Этот конструктор будет получать список инициализаторов в скобках.

class StrBlob {

public:

 typedef std::vector<std::string>::size_type size_type;

 StrBlob();

 StrBlob(std::initializer_list<std::string> il);

 size_type size() const { return data->size(); }

 bool empty() const { return data->empty(); }

 // добавление и удаление элементов

 void push_back(const std::string &t) {data->push_back(t);}

 void pop_back();

 // доступ к элементам

 std::string& front();

 std::string& back();

private:

 std::shared_ptr<std::vector<std::string>> data;

 // передать сообщение при недопустимости data[i]

 void check(size_type i, const std::string &msg) const;

};

В классе будут реализованы функции-члены size(), empty() и push_back(), которые передают свою работу через указатель data внутреннему вектору. Например, функция size() класса StrBlob вызывает функцию data->size() и т.д.

Конструкторы класса StrBlob

Для инициализации своей переменной-члена data указателем на динамически созданный вектор каждый конструктор использует собственный список инициализации (см. раздел 7.1.4). Стандартный конструктор резервирует пустой вектор:

StrBlob::StrBlob(): data(make_shared<vector<string>>()) { }

StrBlob::StrBlob(initializer_list<string> il):

 data(make_shared<vector<string>>(il)) { }

Конструктор, получающий тип initializer_list, передает свой параметр для соответствующего конструктора класса vector (см. раздел 2.2.1). Этот конструктор инициализирует элементы вектора копиями значений из списка.

Функции-члены доступа к элементам

Функции pop_back(), front() и back() обращаются к соответствующим функциям-членам вектора. Эти функции должны проверять существование элементов прежде, чем попытаться получить доступ к ним. Поскольку несколько функций-членов должны осуществлять ту же проверку, снабдим класс закрытой вспомогательной функцией check(), проверяющей принадлежность заданного индекса диапазону. Кроме индекса, функция check() получает аргумент типа string, передаваемый обработчику исключений. Строка описывает то, что пошло не так, как надо:

void StrBlob::check(size_type i, const string &msg) const {

 if (i >= data->size())

  throw out_of_range(msg);

}

Функция pop_back() и функции-члены доступа к элементам сначала вызывают функцию check(). Если проверка успешна, эти функции-члены передают свою работу соответствующим функциям вектора:

strings StrBlob::front() {

 // если вектор пуст, функция check() передаст следующее

 check(0, "front on empty StrBlob");

 return data->front();

}

strings StrBlob::back() {

 check(0, "back on empty StrBlob");

 return data->back();

}

void StrBlob::pop_back() {

 check(0, "pop_back on empty StrBlob");

 data->pop_back();

}

Функции-члены front() и back() должны быть перегружены для констант (см. раздел 7.3.2). Определение этих версий остается в качестве самостоятельного упражнения.

Копирование, присвоение и удаление объектов класса StrBlob

Подобно классу Sales_data, класс StrBlob использует стандартные версии функций копирования, присвоения и удаления объектов (см. раздел 7.1.5). По умолчанию эти функции копируют, присваивают и удаляют переменные-члены класса. У класса StrBlob есть только одна переменная-член — указатель shared_ptr. Поэтому при копировании, присвоении и удалении объекта класса StrBlob его переменная-член shared_ptr будет скопирована, присвоена или удалена.

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

Упражнения раздела 12.1.1

Упражнение 12.1. Сколько элементов будут иметь объекты b1 и b2 в конце этого кода?

StrBlob b1; {

 StrBlob b2 = {"a", "an", "the"};

 b1 = b2;

 b2.push_back("about");

}

Упражнение 12.2. Напишите собственную версию класса StrBlob, включающего константные версии функций front() и back().

Упражнение 12.3. Нуждается ли этот класс в константных версиях функций push_back() и pop_back()? Если они нужны, добавьте их. В противном случае объясните, почему они не нужны?

Упражнение 12.4. В функции check() нет проверки того, что параметр i больше нуля. Почему эта проверка не нужна?

Упражнение 12.5. Конструктор, получающий тип initializer_list, не был объявлен как explicit (см. раздел 7.5.4). Обсудите преимущества и недостатки этого выбора.