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

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

1. В любом из приведенных выше вызовов конструируется временный объект std::shared_ptr, хранящий простой указатель, являющийся результатом операции “ new Widget”. Назовем этот объект temp.

2. Функция push_backполучает tempпо ссылке. В процессе выделения памяти для узла списка, который должен содержать копию temp, генерируется исключение нехватки памяти.

3. При выходе исключения за пределы push_backобъект tempуничтожается. Поскольку это единственный интеллектуальный указатель std::shared_ptr, указывающий на управляемый им объект Widget, он автоматически удаляет последний, в данном случае с помощью вызова killWidget.

Несмотря на происшедшую генерацию исключения нет никаких утечек: Widget, созданный с помощью “ new Widget” в вызове push_back, освобождается деструктором объекта std::shared_ptr, который был создан для управления им (объектом temp). Все отлично.

Рассмотрим теперь, что произойдет при вызове emplace_backвместо push_back:

ptrs. emplace_back(new Widget, killWidget);

1. Обычный указатель, являющийся результатом выполнения “ new Widget”, передается с помощью прямой передачи в точку внутри emplace_back, где выделяется память для узла списка. При попытке выделения памяти генерируется исключение нехватки памяти.

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могут быть построены из символьных строк. Это делает корректным такой полезный код, как

std::regexupperCaseWord("[A-Z]+");

Создание std::regexиз символьной строки может иметь достаточно высокую стоимость, так что для минимизации вероятности непреднамеренных расходов конструктор std::regex, принимающий указатель const char*, объявлен как explicit. Именно поэтому не компилируются следующие строки:

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

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

В обоих случаях требуется неявное преобразование указателя в std::regex, а объявление конструктора как explicitего предотвращает.