c++ - Why would I ever use push_back instead of emplace_back?

itemprop="text">

C++11 vectors have the new function
emplace_back. Unlike push_back, which
relies on compiler optimizations to avoid copies, emplace_back
uses perfect forwarding to send the arguments directly to the constructor to create an
object in-place. It seems to me that emplace_back does
everything push_back can do, but some of the time it will do it
better (but never worse).

What reason
do I have to use push_back?

Answer

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 rel="noreferrer">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
            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>
            v;
T a;
v.emplace_back(std::addressof(a)); //
            compiles
v.push_back(std::addressof(a)); // fails to
            compile

std::unique_ptr
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 *>, but it owned the contents. As part of the migration to C++11, I
correctly changed T * to
std::unique_ptr 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.