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

// queenOfDisco в конце vs

vs. emplace_back(queenOfDisco); // То же самое

Таким образом, размещающие функции могут делать все то же самое, что и функции вставки. Иногда они делают это более эффективно и как минимум теоретически не должны делать менее эффективно. Так почему же мы не используем их все время?

Потому что теоретически разницы между теорией и практикой нет, а практически — есть. При текущих реализациях стандартной библиотеки имеются ситуации, когда, как и ожидается, размещение превосходит вставку, но — увы! — есть ситуации, когда вставка работает быстрее. Такие ситуации непросто охарактеризовать, поскольку они зависят от типов передаваемых аргументов, используемых контейнеров, местоположения вставки или размещения в контейнере, безопасности исключений конструкторов типов, содержащихся в контейнере, и для контейнеров, в которых запрещены дубликаты (т.e. std::set, std::map, std::unordered_set, std::unordered_map), от того, содержится ли уже в контейнере вставляемое значение. А потому следует пользоваться обычным советом по повышению производительности: для определения того, какой метод работает быстрее, надо сравнивать их реальную производительность в конкретных условиях.

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

• Добавляемое значение конструируется в контейнере, а не присваивается. Пример, с которого начат данный раздел (добавление std::stringсо значением "xyzzy"в std::vector vs), демонстрирует значение, добавляемое в конец вектора vs — в место, где пока что нет никакого объекта. Таким образом, новое значение должно быть сконструировано в std::vector. Если мы пересмотрим пример так, что новая строка std::stringбудет направляться в местоположение, уже занятое объектом, это будет совсем другая история:

std::vector vs; // Как и ранее

… // Добавление элементов в vs

vs.emplace( vs.begin(), "xyzzy"); // Добавление "xyzzy" в начало vs

При таком коде только редкие реализации будут конструировать добавляемый объект std::stringв памяти, занятой vs[0]. Большинство реализаций используют перемещающее присваивание в указанное место. Но перемещающее присваивание требует наличия перемещаемого объекта, а это означает, что необходимо создание временного объекта. Поскольку основное преимущество размещения над вставкой заключается в том, что не создаются и не уничтожаются временные объекты, при добавлении значения в контейнер с помощью присваивания преимущества размещения исчезают.

Увы, выполняется ли добавление значения в контейнер путем конструирования или перемещения, в общем случае зависит от реализации. И вновь на помощь может прийти эвристика.

Контейнеры на основе узлов почти всегда используют для добавления новых значений конструирование, а большинство стандартных контейнеров являются именно таковыми. Исключениями являются std::vector, std::dequeи std::string. (Контейнер std::arrayтакже не является таковым, но он не поддерживает ни вставку, ни размещение, поэтому упоминать о нем здесь нет смысла.) В контейнерах, не основанных на узлах, можно рассчитывать на использование функцией emplace_backдля размещения нового значения конструирования вместо присваивания; то же самое можно сказать и о функции emplace_frontконтейнера std::deque.

• Типы передаваемых аргументов отличаются от типа, хранящегося в контейнере. И вновь, преимущество размещения по сравнению со вставкой в общем случае связано с тем фактом, что его интерфейс не требует создания и уничтожения временного объекта при передаче аргументов типа, отличного от типа, хранящегося в контейнере. Когда в контейнер containerдобавляется объект типа T, нет причин ожидать, что размещение окажется быстрее вставки, поскольку для удовлетворения интерфейсу вставки не требуется создание временного объекта.

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

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