Язык программирования C++. Пятое издание - Стенли Липпман

Будет ли использован счетчик или другая структура данных для отслеживания количества указателей на совместно используемый объект, зависит от реализации компилятора. Главное то, что класс отслеживает количество указателей 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 выйдет из области видимости, элементы вектора перестанут существовать. Чтобы гарантировать продолжение существования элементов, будем хранить вектор в динамической памяти.