为什么我会使用 push_back 而不是 emplace_back？

Question

C++11 向量具有新功能 emplace_back 。与 push_back 不同，后者依赖于编译器优化来避免复制， emplace_back 使用完美转发将参数直接发送到构造函数以就地创建对象。在我看来， emplace_back 可以做所有事情 push_back 可以做，但有时它会做得更好（但永远不会更糟）。

我必须使用什么原因 push_back ？

原文由 David Stone 发布，翻译遵循 CC BY-SA 4.0 许可协议

Answer 1

在过去的四年里，我对这个问题思考了很多。我得出的结论是，关于 push_back 与 emplace_back 的大多数解释都错过了全貌。

去年，我在 C++Now 上做了一个关于 C++14 中的类型推导 的演讲。我在 13:49 开始谈论 push_back 与 emplace_back ，但在此之前有一些有用的信息提供了一些支持证据。

真正的主要区别与隐式与显式构造函数有关。考虑我们有一个参数要传递给 push_back 或 emplace_back 的情况。

 std::vector<T> v;
v.push_back(x);
v.emplace_back(x);

在您的优化编译器掌握了这一点之后，就生成的代码而言，这两个语句之间没有区别。传统观点是 push_back 将构造一个临时对象，然后将其移动到 v 而 emplace_back 将转发参数并直接构造它没有副本或移动。根据标准库中编写的代码，这可能是正确的，但它错误地假设优化编译器的工作是生成您编写的代码。如果您是平台特定优化方面的专家并且不关心可维护性，只关心性能，优化编译器的工作实际上是生成您会编写的代码。

这两个语句之间的实际区别在于，更强大的 emplace_back 会调用任何类型的构造函数，而更谨慎的 push_back 只会调用隐式的构造函数。隐式构造函数应该是安全的。 If you can implicitly construct a U from a T , you are saying that U can hold all of the information in T with no失利。在几乎任何情况下，传递一个 T U 人会介意。隐式构造函数的一个很好的例子是从 std::uint32_t 到 std::uint64_t 的转换。隐式转换的一个坏例子是 double 到 std::uint8_t 。

我们希望在编程时保持谨慎。我们不想使用强大的功能，因为功能越强大，就越容易意外地做一些不正确或意想不到的事情。如果您打算调用显式构造函数，那么您需要 emplace_back 的强大功能。如果您只想调用隐式构造函数，请坚持 push_back 的安全性。

一个例子

std::vector<std::unique_ptr<T>> v;
T a;
v.emplace_back(std::addressof(a)); // compiles
v.push_back(std::addressof(a)); // fails to compile

std::unique_ptr<T> 具有来自 T * 的显式构造函数。因为 emplace_back 可以调用显式构造函数，所以传递一个非拥有指针编译就好了。但是，当 v 超出范围时，析构函数将尝试在该指针上调用 delete ，该指针不是由 new 分配的，因为它只是一个堆栈目的。这会导致未定义的行为。

这不仅仅是发明的代码。这是我遇到的一个真正的生产错误。代码是 std::vector<T *> ，但它拥有内容。作为迁移到 C++11 的一部分，我正确地将 T * 更改为 std::unique_ptr<T> 以表明向量拥有它的内存。然而，我是根据我在 2012 年的理解来做出这些改变的，在此期间我认为“ emplace_back --- 可以做所有事情 push_back 可以做更多的事情，所以我为什么要使用 push_back ?”，所以我也将 push_back 更改为 emplace_back 。

如果我将代码保留为使用更安全的 push_back ，我会立即发现这个长期存在的错误，并且它会被视为升级到 C++11 的成功。相反，我掩盖了这个错误，直到几个月后才发现它。

原文由 David Stone 发布，翻译遵循 CC BY-SA 4.0 许可协议

Answer 2

使用 push_back 仅用于原始/内置类型或原始指针。否则使用 emplace_back 。

原文由 KeyC0de 发布，翻译遵循 CC BY-SA 4.0 许可协议