Item 42: Consider emplacement instead of insertion.

如果你有一个容器用于保存 std::string，你可以使用插入函数（例如 insert、push_front、push_back 或 std::forward_list 的insert_after）添加元素。例如：

std::vector<std::string> vs;  // container of std::string
vs.push_back("xyzzy");        // add string literal

这里，std::vector 的类型是 std::string，而插入的是字面值字符串（const char[6]）。std::vector 的 push_back 重载了左值和右值引用：

template <class T,                         // from the C++11
          class Allocator = allocator<T>>  // Standard
class vector {                           
public:
  ...
  void push_back(const T& x);  // insert lvalue
  void push_back(T&& x);       // insert rvalue
  ...
};

对于下面的调用：

vs.push_back("xyzzy");

由于实参的类型（const char[6]）和 push_back 形参类型（std::string 引用）类型不匹配，编译器会使用字符串字面值创建一个临时的 std::string 对象，再将这个临时对象传给 push_back，类似如下语义：

vs.push_back(std::string("xyzzy")); // create temp. std::string
                                    // and pass it to push_back

我们再仔细分解一下编译器的行为如下：

1. 使用字面值 "xyzzy" 创建临时的 std::string 对象（记为 temp），这里调用一次 std::string 的构造函数。并且 temp 是一个右值。
2. temp 接着被传入右值引用重载的 push_back，也即将 temp 拷贝给 x。接着将 x 放入 vs 中，这里调用移动构造函数完成。
3. 最后 temp 被销毁，调用 std::string 的析构函数。

我们只是将字符串字面值传给 std::string 容器，却要调用两次构造和一次析构，对于追求代码性能的程序员而言，这个性能开销可能是无法接受的。

解决方案是使用 emplace_back 代替：

vs.emplace_back("xyzzy"); // construct std::string inside
                          // vs directly from "xyzzy"

emplace_back 使用了完美转发机制，如果传入的是右值，将直接使用这个右值在容器内部完成元素的构造。使用 emplace_back 将不会创建临时的 std::string 对象，将使用传入的字符串字面值（"xyzzy"）直接在容器内构造 std::string 对象。只要传入的参数合法，emplace_back 可以接收任意参数，然后完美转发到容器内部直接构造容器的元素。例如：

vs.emplace_back(50, 'x'); // insert std::string consisting
                          // of 50 'x' characters

emplace 系列接口和传统插入接口不同之处在于它可以接收可变参数，并且采用了完美转发机制，可以直接使用传入参数来构造容器元素（必须匹配到容器元素的构造函数）。而传统插入接口必须要插入和容器元素类型完全相同的对象。emplace 的优势是避免了临时对象的构造和析构。如果直接插入容器元素对象，那么二者是等价的，例如：

vs.push_back(queenOfDisco);     // copy-construct queenOfDisco
                                // at end of vs
                                
vs.emplace_back(queenOfDisco);  // ditto

emplace 接口可以实现传统插入接口能做的所有事情，并且理论上，emplace 接口有时更高效。但实际却情况并非完全如此，虽然多数场景下，emplace 接口要比传统插入接口更加高效。但在少数场景下，传统插入接口要比 emplace 接口更加高效，这样的场景并不好归类，因为这取决于多种因素，例如传入参数的类型、使用的容器、插入容器中的位置、容器元素构造函数的异常安全机制、容器是否允许插入重复值、要插入的元素是否已经在容器中等。因而，给性能调优的建议是性能实测。

当然还是有一定的办法帮你来识别，如果以下条件都满足，emplace 接口几乎肯定要比传统插入接口更加高效：

• 要插入的值是通过构造函数插入容器，而非赋值。上面插入的字符串字面值就是这种情况，但如果插入的位置已经有元素了，情况就不同了，例如：

std::vector<std::string> vs; 
vs.emplace(vs.begin(), "xyzzy");  // add "xyzzy" to
                                  // beginning of vs

很少有编译器采用构造的方法将元素插入已经存在容器中存在的问题（这里是 vs[0]），而多数采用移动赋值的方法插入到已存在的位置。移动赋值需要被移动的对象，这就意味着需要构造临时的对象。那么 emplace 不会有临时对象的构造和析构的优势也就不存在了。

• 传入参数的类型和容器元素的类型不同。emplace 的优势是需要构造临时的对象，如果传参的类型和容器元素的类型相同，也就不会产生临时对象了，emplace 的优势也就不存在了。
• 容器不大可能因为元素值重复而拒绝其加入。这就意味着要不容器允许重复值加入，要不新加入的值大多数是唯一的。这样要求的原因是因为为了检测一个新值是否已经存在， emplace 的实现通常会创建一个新值的节点，然后和容器中已存在节点的值相比较，如果新节点的值不在容器中，则链接该节点。如果新节点的值已经在容器中，新创建的节点就要被销毁，这意味着新节点的构造和销毁就浪费了。

下面的调用完全满足上面的条件，因而 empalce_back 比 push_back 要高效。

vs.emplace_back("xyzzy");  // construct new value at end of
                           // container; don't pass the type in
                           // container; don't use container
                           // rejecting duplicates
vs.emplace_back(50, 'x');  // ditto

在决定是否使用 emplace 的时候，还有另外两个因素需要注意。第一个因素就是资源管理。例如：

std::list<std::shared_ptr<Widget>> ptrs;

如果你要添加一个自定义 deleter 的 std::shared_ptr 对象，那么无法使用 std::make_shared_ptr 来创建（详见Item 21）。只能使用 std::shared_ptr 管理原始指针：

void killWidget(Widget* pWidget);

ptrs.push_back(std::shared_ptr<Widget>(new Widget, killWidget));
// ptrs.push_back({ new Widget, killWidget });  // ditto

这样会先创建一个临时的 std::shared_ptr 对象，然后再传给 push_back。如果使用 emplace 接口，原则上临时对象的创建是可以避免的，但是这里创建临时对象却是必要的，考虑下面的过程：

1. 首先，临时的 std::shared_ptr<Widge> 对象（temp）被创建。
2. 然后， push_back 接受 temp 的引用。在 分配节点（用于接收 temp 的拷贝）的时候发生 OOM（out-of-memory）。
3. 最后，异常从 push_back 传出后，temp 被销毁，它所管理的 Widget 对象也通过 killWidget 进行释放。

而如果使用 empalce 接口：

ptrs.emplace_back(new Widget, killWidget);

1. new Widget 创建的原始指针被完美转发到 emplace_back 内部构造器，此时发生 OOM。
2. 异常从 push_back 传出后，原始指针是 Widget 唯一访问路径，它直接被销毁，但其管理的内存却没办法释放，就会发生内存泄漏。

对于 std::unique_ptr 也有类似的问题。出现这样问题的根本原因是 std::shared_ptr 和 std::unique_ptr 对资源的管理取决于它们是否立即接管了这个资源，而 emplace 的完美转发机制延迟了资源管理对象的创建，这就给资源异常留下了可能的机会。这也是为什么建议使用 std::make_shared 和 std::make_unique 创建对象的原因。其实不应该将 “new Widget” 这样的表达式直接传给传统插入和 emplace 这样的函数，而应该直接传智能指针对象，像下面这样：

std::shared_ptr<Widget> spw(new Widget,  // create Widget and
                            killWidget); // have spw manage it
ptrs.push_back(std::move(spw));          // add spw as rvalue

或者：

std::shared_ptr<Widget> spw(new Widget, killWidget);
ptrs.emplace_back(std::move(spw));

两种方式都可以避免内存泄漏的问题，同时 emplace 的性能和传统插入接口也是一致的。

使用 emplace 第二个值得注意的因素是它和显示构造函数的交互。C++11 支持了正则表达式，假设创建一个存放正则表达式的容器：

std::vector<std::regex> regexes;

如果不小心写出了下面的错误代码：

regexes.emplace_back(nullptr); // add nullptr to container
                               // of regexes?

nullptr 不是正则表达式，为什么编译不会报错？例如：

std::regex r = nullptr; // error! won't compile

而使用 push_back 接口就是会报错：

regexes.push_back(nullptr); // error! won't compile

这背后的原因是使用字符串构造 std::regex 对象比较耗时，为此 std::regex 禁止隐式构造，采用 const char* 指针的std::regex 构造函数是显式的。这也就是下面代码无法编译通过的原因了：

std::regex r = nullptr;     // error! won't compile
regexes.push_back(nullptr); // error! won't compile

使用 emplace 接口，由于完美转发机制，最后在容器内部直接拿到 const char* 显示构造 std::regex ，因此。下面的代码可以编译通过：

regexes.emplace_back(nullptr); // can compile

总而言之，使用 emplace 接口时一定要注意传入参数的正确性。

参考：

• Effective Modern C++