问是否存在用push_back替换emplace_back不正确的情况？

EN

我构造了一个简短的示例，当push_back被emplace_back替换时，它实际上无法编译。

#include <vector>
struct S {
    S(double) {}
  private:
    explicit S(int) {}
};
int main() {
    std::vector<S>().push_back(0); // OK
    std::vector<S>().emplace_back(0); // error!
}

对push_back的调用需要将其参数0从int类型转换为S类型。因为这是一个隐式转换，所以不考虑显式构造函数S::S(int)，并且调用S::S(double)。另一方面，emplace_back执行直接初始化，因此考虑了S::S(double)和S::S(int)。后者是一个更好的匹配，但它是private，所以程序是错误的.

在异常情况下，emplace版本根本不创建所需类型的对象。这可能会导致一个错误。

考虑下面的示例，它使用std::vector来简化操作(假设uptr的行为类似于std::unique_ptr，除非构造函数不是显式的)：

std::vector<uptr<T>> vec;
vec.push_back(new T());

它是例外安全的。创建一个临时uptr<T>以传递给push_back，后者被移动到向量中。如果向量重新分配失败，则分配的T仍然由一个正确删除它的智能指针所拥有。

与之相比：

std::vector<uptr<T>> vec;
vec.emplace_back(new T());

不允许emplace_back创建临时对象。ptr将在向量中创建一次.如果重新分配失败，就没有就地创建的位置，也不会创建任何智能指针。T将被泄露。

当然，最好的选择是：

std::vector<std::unique_ptr<T>> vec;
vec.push_back(make_unique<T>());

这相当于第一个，但使智能指针创建显式。

如果您在向量中持有的对象的复制构造函数中没有疯狂的副作用，则不会。

引入emplace_back是为了优化不必要的复制和移动。