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

• Маловероятно, что контейнер отвергает новое значение как дубликат. Это означает, что либо контейнер разрешает наличие дубликатов, либо большинство передаваемых значений уникальны. Это важно, поскольку для того, чтобы определить наличие дубликата, реализации размещения обычно создают узел с новым значением, а затем сравнивают его с имеющимися узлами контейнера. Если добавляемое значение в контейнере отсутствует, узел встраивается в контейнер. Однако, если такое значение уже есть в контейнере, размещение прерывается, а узел уничтожается, так что впустую расходуется стоимость создания и уничтожения объекта. Такие узлы для функций размещения создаются более часто, чем для функций вставки.

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

vs.emplace_back("xyzzy"); // Конструирует новое значение в конце
                          // контейнера; тип аргумента отличен от
                          // типа, хранимого в контейнере;
                          // контейнер не отвергает дубликаты
vs.emplace_back(50, 'x'); // То же самое

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

std::list> ptrs;

и вы хотите добавить std::shared_ptr, который должен быть освобожден с помощью пользовательского удалителя (см. раздел 4.2). В разделе 4.4 поясняется, что по возможности вы должны использовать для создания std::shared_ptr функцию std::make_shared, но в нем же указано, что существуют ситуации, когда это невозможно. Одна из таких ситуаций — когда вы хотите указать пользовательский удалитель. В этом случае для получения обычного указателя, которым будет управлять интеллектуальный указатель std::shared_ptr, вы должны непосредственно использовать оператор new.

Если пользовательский удалитель представляет собой функцию

void killWidget(Widget* pWidget);

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

ptrs.push_back(std::shared_ptr(new Widget, killWidget));

Он может также принять и такой вид, означающий то же самое:

ptrs.push_back({ new Widget, killWidget });

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

Функция 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>), типы параметров функций в общем случае гарантируют, что между захватом ресурса (например, использованием оператора