Скотт Мейерс - Эффективный и современный С++. 42 рекомендации по использованию С++11 и С++14

Пока указатели std::weak_ptrуказывают на управляющий блок (т.e. слабый счетчик больше нуля), этот управляющий блок должен продолжать существовать. А пока существует управляющий блок, память, его содержащая, должна оставаться выделенной. Таким образом, память, выделенная mаkе-функцией для std::shared_ptrне может быть освобождена до тех пор, пока не будут уничтожены последний указатель std::shared_ptr и последний указатель std::weak_ptr, ссылающиеся на объект.

Если время между уничтожением последнего std::shared_ptrи последнего std::weak_ptrзначительно, между уничтожением объекта и занимаемой им памятью может происходить задержка, что особенно важно для типов с большим размером:

class ReallyBigType { … };

auto pBigObj = // Создание большого

std::make_shared(); // объекта с помощью

// std::make_shared

… // Создание указателей std::shared_ptr и std::weak_ptr

// на большой объект и работа с ними

… // Уничтожение последнего указателя std::shared_ptr на

// этот объект; остаются указатели std::weak_ptr

… //Во время этого периода память, ранее занятая большим

// объектом, остается занятой

… // Уничтожение последнего указателя std::weak_ptr на

// объект; освобождение памяти, выделенной для

// управляющего блока и объекта

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

class ReallyBigType { … }; // Как и ранее

// Создание очень большого объекта с помощью new:

std::shared_ptr pBigObj( newReallyBigType);

… // Как и ранее, создание указателей std::shared_ptr и

// std::weak_ptr на объект и работа с ними

… // Уничтожение последнего указателя std::shared_ptr на

// этот объект; остаются указатели std::weak_ptr

// Память, выделенная для объекта, освобождается

… //Во время этого периода остается занятой только память,

// ранее выделенная для управляющего блока

… // Уничтожение последнего указателя std::weak_ptr на

// объект; освобождение памяти, выделенной для

// управляющего блока

Оказавшись в ситуации, когда использование функции std::make_sharedневозможно или неприемлемо, вы можете захотеть защититься от ранее рассматривавшихся нами проблем, связанных с безопасностью исключений. Лучший способ сделать это — обеспечить немедленную передачу результата операции newконструктору интеллектуального указателя в инструкции, которая не делает ничего иного . Это предотвратит создание компилятором кода, который может генерировать исключение между оператором newи вызовом конструктора интеллектуального указателя, который будет управлять объектом, созданным оператором new.

В качестве примера рассмотрим небольшое изменение небезопасного с точки зрения исключений вызова функции processWidget, которую мы рассматривали ранее. В этот раз мы укажем пользовательский удалитель:

void processWidget(std::shared_ptr spw, // Как и ранее

int priority);

void cusDel(Widget *ptr); // Пользовательский удалитель

Вот небезопасный с точки зрения исключений вызов:

processWidget( // Как и ранее,

std::shared_ptr(new Widget,cusDel), // потенциальная

computePriority() // утечка

); // ресурса!

Вспомним: если computePriorityвызывается после new Widget, но до конструктора std::shared_ptrи если computePriorityгенерирует исключение, происходит утечка динамически созданного Widget.

Здесь применение пользовательского удалителя препятствует использованию std::make_shared, так что избежать проблемы можно, поместив создание Widgetв динамической памяти и конструирование std::shared_ptrв собственную инструкцию, а затем вызвав функцию processWidgetс передачей ей полученного std::shared_ptr. Вот и вся суть этого метода, хотя, как мы вскоре увидим, его можно подкорректировать для повышения производительности:

std::shared_ptr spw(new Widget, cusDel);

processWidget(spw, computePriority()); // Корректно, но не

// оптимально; см. ниже

Этот код работает, поскольку std::shared_ptrпредполагает владение обычным указателем, переданным конструктору, даже если этот конструктор генерирует исключение. В данном примере, если конструктор spwгенерирует исключение (например, из-за невозможности выделить динамическую память для управляющего блока), он все равно гарантирует вызов cusDelдля указателя, полученного в результате операции new Widget.

Небольшое снижение производительности возникает из-за того, что в небезопасном с точки зрения исключений коде мы передавали функции processWidgetrvalue.

processWidget (

std::shared_ptr(new Widget, cusDel), // rvalue

computePriority()

);

а в случае безопасного вызова — передаем lvalue:

processWidget( spw, computePriority()); // lvalue

Поскольку параметр std::shared_ptrфункции processWidgetпередается по значению, создание из rvalueвлечет за собой только перемещение, в то время как создание из lvalue требует копирования. Для указателя std::shared_ptrразница может оказаться существенной, так как копирование std::shared_ptrтребует атомарного инкремента счетчика ссылок, в то время как перемещение std::shared_ptrне требует никаких действий со счетчиком ссылок вообще. Чтобы безопасный с точки зрения исключений код достиг уровня производительности небезопасного кода, нам надо применить std: :moveк spwдля того, чтобы превратить его в rvalue(см. раздел 5.1):

processWidget( std::move(spw ), // Эффективно и безопасно

computePriority()); // в смысле исключений

Это интересный метод, и его стоит знать, но обычно это не имеет особого значения, поскольку вы будете редко сталкиваться с причинами не использовать make-функцию. Если у вас нет убедительных причин поступать иначе, используйте make-функции.

• По сравнению с непосредственным использованием new, make-функции устраняют дублирование кода, повышают безопасность кода по отношению к исключениям и в случае функций std::make_sharedи std::allocate_sharedгенерируют меньший по размеру и более быстрый код.

• Ситуации, когда применение makе-функций неприемлемо, включают необходимость указания пользовательских удалителей и необходимость передачи инициализаторов в фигурных скобках.

• Для указателей std::shared_ptrдополнительными ситуациями, в которых применение makе-функций может быть неблагоразумным, являются классы с пользовательским управлением памятью и системы, в которых проблемы с объемом памяти накладываются на использование очень больших объектов и наличие указателей std::weak_ptr, время жизни которых существенно превышает время жизни указателей std::shared_ptr.