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

2. При выходе исключения за пределы emplace_backобычный указатель, который был единственным средством доступа к Widgetв динамической памяти, оказывается потерянным. Происходит утечка Widget(и всех ресурсов, которыми владеет этот объект).

В этом сценарии все совсем не отлично, и класс std::shared_ptrв этом не повинен. Та же самая проблема возникнет при использовании std::unique_ptrс пользовательским удалителем. По существу, эффективность классов управления ресурсами, таких как std::shared_ptrи std::unique_ptr, основана на немедленной передаче ресурсов (таких, как обычные указатели, возвращаемые оператором new) конструкторам управляющих ресурсами объектов. Тот факт, что функции наподобие std::make_sharedи std::make_uniqueавтоматизируют этот процесс, является одной из причин, по которым эти функции так важны.

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

Откровенно говоря, вы в любом случае не должны передавать выражения наподобие “ new Widget” в функции emplace_backи push_back, как и в большинство любых других функций, поскольку, как поясняется в разделе 4.4, это ведет к возможным проблемам с безопасностью исключений, одну из которых мы только что рассмотрели. Для предотвращения неприятностей требуется, чтобы получение указателя от “ new Widget” и превращение его в управляющий ресурсом объект выполнялось в одной инструкции, а уже затем этот объект передавался как rvalue функции, которой вы хотели изначально передавать “ new Widget”. (Более детально этот подход рассматривается в разделе 4.4.) Таким образом, код, использующий push_back, должен быть записан скорее как

std::shared_ptr spw(new Widget, // Создание Widget и

killWidget);// передача его spw

ptrs.push_back(std::move(spw)); // Добавление spw

// как rvalue

Версия с использованием emplace_backаналогична:

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

ptrs.emplace_back(std::move(spw));

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

Вторым важным аспектом функций размещения является их взаимодействие с конструкторами, объявленными как explicit. Предположим, что вы создаете контейнер объектов регулярных выражений С++11:

std::vector regexes;

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

regexes. emplace_back(nullptr);

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

std::regex r = nullptr;// Ошибка! Не компилируется!

компилятор отвергнет такой код. Интересно, что будет отвергнут и вызов push_backвместо emplace_back:

regexes. push_back(nullptr); // Ошибка! Не компилируется!

Такое любопытное поведение поясняется тем, что объекты std::regexмогут быть построены из символьных строк. Это делает корректным такой полезный код, как