←back to thread

178 points todsacerdoti | 1 comments | | HN request time: 0s | source
Show context
TonyTrapp ◴[] No.26340399[source]
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.

replies(4): >>26340422 #>>26340494 #>>26340600 #>>26341355 #
MaxBarraclough ◴[] No.26341355[source]
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.
replies(4): >>26341490 #>>26341620 #>>26342083 #>>26342447 #
Sebb767 ◴[] No.26341490[source]
> To say that something isn't magic is an empty statement

I think this is said to express "simply replacing that function call/method/... without changing your calls/methods/coding style is not going to magically solve your problems". Which is true in the push_back/emplace_back case (you need to adjust your call).

GC, on the other hand, is magic pixie dust, if my definition is correct ;)

replies(1): >>26341591 #
1. MaxBarraclough ◴[] No.26341591{3}[source]
> I think this is said to express "simply replacing that function call/method/... without changing your calls/methods/coding style is not going to magically solve your problems"

I agree, but you're doing all the work in conjuring this interpretation. Saying it's not magic doesn't say anything substantial.

If it were possible to mechanically replace all references to push_back by emplace_back for an easy performance boost, then we wouldn't need emplace_back to be its own member function, it would just be a compiler optimisation. You have to make shallow and localised changes to make proper use of emplace_back, but isn't that the best we can hope for? Far easier than parallelism, say, where sweeping architectural changes may be necessary.