Don’t blindly prefer emplace_back to push_back

Don’t blindly prefer emplace_back to push_back*

*when using it incorrectly. The premise of of emplace_back is that you use it for calling the constructor of the object in place. Obviously it won't help you if you call a copy constructor instead. I find this article a bit pointless. Clang's suggestion was spot-on and emplace_back would have (potentially) helped if the suggestion was actually followed correctly.

The article goes even further than that: When all else is equal, prefer push_back to emplace_back. It still shows the example of using emplace_back with a pre-existing object, which as you say, isn't the point of emplace_back. It also states that it's more work for the compiler, stating that the template resolution seems more complex, and suggesting it's likely to bloat compile times. That's a more persuasive point (hard numbers are provided at the end of the article), I wonder if more work has been done on this.

The author seems to be an advanced C++ programmer, but doesn't seem to properly acknowledge that, as you say, The premise of of emplace_back is that you use it for calling the constructor of the object in place. The only instance of proper use of emplace_back is in

    widgets.emplace_back(foo, bar, baz);

I was surprised to see no follow-up for this example:

    auto w = Widget(1,2,3);
    widgets.emplace_back(w);  // Fixed? Nope!

No mention of the obvious fix:

    widgets.emplace_back(1,2,3);

I don't mean to 'pile on', but, a pet peeve of mine: emplace_back is not magic C++11 pixie dust. This isn't saying anything. You could say garbage collection isn't magic, or error-correcting codes aren't magic, or sound type systems aren't magic. To say that something isn't magic is an empty statement, especially when it's something like emplace_back which introduces an important new ability.

> auto w = Widget(1,2,3);

Note that unlike in Java or C# this is not the right way to initialize a variable in C++.

Herb Sutter offers another viewpoint:

In particular: #5 on that page: "we see that the right-hand style is not only more robust and maintainable for the reasons already given, but also arguably cleaner and more regular with the type consistently on the right when it is mentioned"

[1] https://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style...

I don't think Herb's points apply to an ordinary declare-an-object-and-immediately-initialize-using-the-constructor, do they?

He gives an example using aggregate initialization, but that's not the same thing:

    // Classic C++ declaration order     // Modern C++ style

    employee e{ empid };                 auto e = employee{ empid };
    widget w{ 12, 34 };                  auto w = widget{ 12, 34 };

He makes the case that it's nicer to use auto pretty much wherever we can, to avoid repeating ourselves regarding type, and to avoid unexpected conversions. The auto keyword doesn't apply in our case, there's no way to use auto to simplify a statement like:

    Widget w(1,2,3);