为啥我会使用 push_back 而不是 emplace_back？

Posted 2023-02-18

【中文标题】为啥我会使用 push_back 而不是 emplace_back？

【英文标题】：Why would I ever use push_back instead of emplace_back?为什么我会使用 push_back 而不是 emplace_back？

【发布时间】：2012-06-09 01:52:18

【问题描述】：

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

我有什么理由使用push_back？

【参考方案1】：

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

去年，我在 C++Now 上的 Type Deduction in 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 将仅调用隐式构造函数。隐式构造函数应该是安全的。如果您可以从T 隐式构造U，那么您就是说U 可以毫无损失地保存T 中的所有信息。在几乎任何情况下传递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？”，所以我也改变了@987654359 @到emplace_back。

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

【讨论】：

如果您能详细说明 emplace 在您的示例中究竟做了什么，以及为什么它是错误的，这将有所帮助。

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

感谢您发布此信息。当我写答案时我不知道它，但现在我希望我在以后学习它时自己写它:) 我真的很想给那些切换到新功能只是为了做他们能找到的最时髦的事情的人.伙计们，在 C++11 之前人们也在使用 C++，并不是关于它的一切都是有问题的。 如果您不知道为什么要使用某项功能，请不要使用它。很高兴你发布了这个，我希望它得到更多的支持，所以它超过了我的。 +1

@CaptainJacksparrow：看起来我说的是含蓄的和明确的。你混淆了哪一部分？

@CaptainJacksparrow：explicit 构造函数是一个应用了关键字explicit 的构造函数。 “隐式”构造函数是任何没有该关键字的构造函数。对于来自T * 的std::unique_ptr 的构造函数，std::unique_ptr 的实现者编写了该构造函数，但这里的问题是该类型的用户称为emplace_back，它调用了该显式构造函数。如果它是push_back，而不是调用那个构造函数，它会依赖一个隐式转换，它只能调用隐式构造函数。

【参考方案2】：

push_back 总是允许使用统一初始化，这是我非常喜欢的。例如：

struct aggregate 
    int foo;
    int bar;
;

std::vector<aggregate> v;
v.push_back( 42, 121 );

另一方面，v.emplace_back( 42, 121 ); 将不起作用。

【讨论】：

请注意，这只适用于聚合初始化和初始化器列表初始化。如果您要使用 语法来调用实际的构造函数，那么您可以删除 并使用emplace_back。

愚蠢的提问时间：所以 emplace_back 根本不能用于结构向量？或者只是不使用文字 42,121 的这种风格？

@LucDanton：正如我所说，它只适用于 aggregate 和 initializer-list 初始化。您可以使用 语法来调用实际的构造函数。您可以给aggregate 一个接受2 个整数的构造函数，并且在使用 语法时将调用此构造函数。关键是，如果您 尝试 调用构造函数，emplace_back 会更可取，因为它会就地调用构造函数。因此不需要类型是可复制的。

这被视为标准中的一个缺陷，并已得到解决。见cplusplus.github.io/LWG/lwg-active.html#2089

@DavidStone 如果它已经解决，它不会仍然在“活动”列表中......不是吗？这似乎仍然是一个悬而未决的问题。最新的更新，标题为“[2018-08-23 Batavia Issues processing]”，表示“P0960（目前正在运行中）应该可以解决这个问题。”而我在没有显式编写样板构造函数的情况下，仍然无法编译尝试 emplace 聚合的代码。目前还不清楚它是否会被视为缺陷并因此有资格进行反向移植，或者 C++

【参考方案3】：

向后兼容 C++11 之前的编译器。

【讨论】：

这似乎是 C++ 的诅咒。我们在每个新版本中都会获得大量很酷的功能，但很多公司要么出于兼容性考虑而坚持使用某些旧版本，要么不鼓励（如果不是禁止）使用某些功能。

@Mehrdad：当您可以拥有出色时，为什么还要满足于足够？我肯定不想在blub 中编程，即使它已经足够了。并不是说这个例子就是这种情况，但作为一个为了兼容性而花费大部分时间在 C89 中编程的人，这绝对是一个真正的问题。

我认为这不是问题的真正答案。对我来说，他要求的是push_back 更可取的用例。

@Mr.Boy：当您希望向后兼容 C++11 之前的编译器时，最好使用它。我的回答不清楚吗？

这比我预想的得到了更多的关注，所以对于所有阅读本文的人来说：emplace_back 不是 push_back 的“伟大”版本。这是它的潜在危险版本。 阅读其他答案。

【参考方案4】：

emplace_back 的某些库实现的行为与 C++ 标准中指定的不同，包括 Visual Studio 2012、2013 和 2015 附带的版本。

为了适应已知的编译器错误，如果参数引用迭代器或其他在调用后将无效的对象，请优先使用std::vector::push_back()。

std::vector<int> v;
v.emplace_back(123);
v.emplace_back(v[0]); // Produces incorrect results in some compilers

在一个编译器上，v 包含值 123 和 21，而不是预期的 123 和 123。这是因为第二次调用 emplace_back 会导致调整大小，此时 v[0] 变得无效。

上述代码的工作实现将使用push_back() 而不是emplace_back()，如下所示：

std::vector<int> v;
v.emplace_back(123);
v.push_back(v[0]);

注意：使用整数向量是出于演示目的。我在一个包含动态分配的成员变量的更复杂的类中发现了这个问题，并且对 emplace_back() 的调用导致了严重崩溃。

【讨论】：

对 emplace_back() 的调用使用完美转发来执行就地构造，因此在调整向量大小之前不会评估 v[0]（此时 v[0] 无效） . push_back 构造新元素并根据需要复制/移动元素，并在任何重新分配之前评估 v[0]。

@David - 虽然新空间必须在旧空间被销毁之前存在，但我认为在评估 emplace_back 参数时没有任何保证。完美转发可以延迟评估。据我观察，旧的向量迭代器在我测试的编译中评估参数之前变得无效，并且细节在很大程度上取决于实现。

@Marc：标准保证 emplace_back 即使对范围内的元素也有效。

@DavidStone：请提供一个参考，说明在标准中的哪些地方可以保证这种行为？无论哪种方式，Visual Studio 2012 和 2015 都会表现出不正确的行为。

@cameino：emplace_back 的存在是为了延迟对其参数的评估，以减少不必要的复制。该行为要么是未定义的，要么是编译器错误（待分析标准）。我最近对 ​​Visual Studio 2015 进行了相同的测试，在 Release x64 下得到 123,3，在 Release Win32 下得到 123,40，在 Debug x64 和 Debug Win32 下得到 123,-572662307。

【参考方案5】：

考虑使用 c++-17 编译器在 Visual Studio 2019 中发生的情况。我们在一个函数中有 emplace_back 并设置了正确的参数。然后有人更改了 emplace_back 调用的构造函数的参数。 VS中没有任何警告，代码也编译得很好，然后在运行时崩溃。在此之后，我从代码库中删除了所有 emplace_back。

【讨论】：

我不明白你的问题是什么。