【发布时间】:2012-06-09 01:52:18
【问题描述】:
C++11 向量具有新函数emplace_back。与依赖编译器优化来避免复制的push_back 不同,emplace_back 使用完美转发将参数直接发送到构造函数以就地创建对象。在我看来,emplace_back 做了所有push_back 可以做的事情,但有时它会做得更好(但绝不会更糟)。
我有什么理由使用push_back?
【问题讨论】:
C++11 向量具有新函数emplace_back。与依赖编译器优化来避免复制的push_back 不同,emplace_back 使用完美转发将参数直接发送到构造函数以就地创建对象。在我看来,emplace_back 做了所有push_back 可以做的事情,但有时它会做得更好(但绝不会更糟)。
我有什么理由使用push_back?
【问题讨论】:
在过去的四年里,我对这个问题思考了很多。我得出的结论是,大多数关于 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 的成功。相反,我掩盖了这个错误,直到几个月后才发现它。
【讨论】:
std::unique_ptr<T> 有一个来自T * 的显式构造函数。因为emplace_back 可以调用显式构造函数,所以传递一个非拥有指针编译就好了。但是,当v 超出范围时,析构函数将尝试在该指针上调用delete,该指针不是由new 分配的,因为它只是一个堆栈对象。这会导致未定义的行为。
explicit 构造函数是一个应用了关键字explicit 的构造函数。 “隐式”构造函数是任何没有该关键字的构造函数。对于来自T * 的std::unique_ptr 的构造函数,std::unique_ptr 的实现者编写了该构造函数,但这里的问题是该类型的用户称为emplace_back,它调用了该显式构造函数。如果它是push_back,而不是调用那个构造函数,它会依赖一个隐式转换,它只能调用隐式构造函数。
push_back 总是允许使用统一初始化,这是我非常喜欢的。例如:
struct aggregate {
int foo;
int bar;
};
std::vector<aggregate> v;
v.push_back({ 42, 121 });
另一方面,v.emplace_back({ 42, 121 }); 将不起作用。
【讨论】:
{} 语法来调用实际的构造函数,那么您可以删除{} 并使用emplace_back。
{} 语法来调用实际的构造函数。您可以给aggregate 一个接受2 个整数的构造函数,并且在使用{} 语法时将调用此构造函数。关键是,如果您 尝试 调用构造函数,emplace_back 会更可取,因为它会就地调用构造函数。因此不需要类型是可复制的。
emplace 聚合的代码。目前还不清楚它是否会被视为缺陷并因此有资格进行反向移植,或者 C++
向后兼容 C++11 之前的编译器。
【讨论】:
push_back 更可取的用例。
emplace_back 不是 push_back 的“伟大”版本。这是它的潜在危险版本。 阅读其他答案。
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() 的调用导致了严重崩溃。
【讨论】:
考虑使用 c++-17 编译器在 Visual Studio 2019 中发生的情况。我们在一个函数中有 emplace_back 并设置了正确的参数。然后有人更改了 emplace_back 调用的构造函数的参数。 VS中没有任何警告,代码也编译得很好,然后在运行时崩溃。在此之后,我从代码库中删除了所有 emplace_back。
【讨论】: