Why would I ever use push_back instead of emplace_back?

c++, c++11, std

Solution

I have thought about this question quite a bit over the past four years. I have come to the conclusion that most explanations about `push_back` vs. `emplace_back` miss the full picture.

Last year, I gave a presentation at C++Now on Type Deduction in C++14. I start talking about `push_back` vs. `emplace_back` at 13:49, but there is useful information that provides some supporting evidence prior to that.

The real primary difference has to do with implicit vs. explicit constructors. Consider the case where we have a single argument that we want to pass to `push_back` or `emplace_back`.

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

After your optimizing compiler gets its hands on this, there is no difference between these two statements in terms of generated code. The traditional wisdom is that `push_back` will construct a temporary object, which will then get moved into `v` whereas `emplace_back` will forward the argument along and construct it directly in place with no copies or moves. This may be true based on the code as written in standard libraries, but it makes the mistaken assumption that the optimizing compiler's job is to generate the code you wrote. The optimizing compiler's job is actually to generate the code you would have written if you were an expert on platform-specific optimizations and did not care about maintainability, just performance.

The actual difference between these two statements is that the more powerful `emplace_back` will call any type of constructor out there, whereas the more cautious `push_back` will call only constructors that are implicit. Implicit constructors are supposed to be safe. 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 loss. It is safe in pretty much any situation to pass a `T` and no one will mind if you make it a `U` instead. A good example of an implicit constructor is the conversion from `std::uint32_t` to `std::uint64_t`. A bad example of an implicit conversion is `double` to `std::uint8_t`.

We want to be cautious in our programming. We do not want to use powerful features because the more powerful the feature, the easier it is to accidentally do something incorrect or unexpected. If you intend to call explicit constructors, then you need the power of `emplace_back`. If you want to call only implicit constructors, stick with the safety of `push_back`.

An example

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>` has an explicit constructor from `T *`. Because `emplace_back` can call explicit constructors, passing a non-owning pointer compiles just fine. However, when `v` goes out of scope, the destructor will attempt to call `delete` on that pointer, which was not allocated by `new` because it is just a stack object. This leads to undefined behavior.

This is not just invented code. This was a real production bug I encountered. The code was `std::vector<T *>`, but it owned the contents. As part of the migration to C++11, I correctly changed `T *` to `std::unique_ptr<T>` to indicate that the vector owned its memory. However, I was basing these changes off my understanding in 2012, during which I thought "`emplace_back` does everything `push_back` can do and more, so why would I ever use `push_back`?", so I also changed the `push_back` to `emplace_back`.

Had I instead left the code as using the safer `push_back`, I would have instantly caught this long-standing bug and it would have been viewed as a success of upgrading to C++11. Instead, I masked the bug and didn't find it until months later.

Problem

Original source