1

I know of general idea of emplace functions on containers("construct new element inplace").
My question is not what it does, but more of like Effective C++11 one.

What are good rules for deciding when to use (for eg when it comes to std::vector) emplace_back() and when to use push_back() and in general emplace* vs "old" insert functions?

NoSenseEtAl
  • 28,205
  • 28
  • 128
  • 277
  • Use `emplace` on non-copyable types. – Rapptz Jul 27 '13 at 00:26
  • @Rapptz what if it is noncopyable but movable, aka unique_ptr? – NoSenseEtAl Jul 27 '13 at 00:27
  • 1
    My first thought is _always_ use `emplace`. I can't immediately think of a reason to use `push_back`. I must be forgetting something – Mooing Duck Jul 27 '13 at 00:29
  • @MooingDuck ofc that is a legit posibility... but ofc I would prefer have it blessed by nice A on SO than pulling it out of my noobish analysis – NoSenseEtAl Jul 27 '13 at 00:31
  • 1
    @MooingDuck This question specifically states that the OP knows what `emplace_back` does. The question you linked is *what does emplace_back do*. – Rapptz Jul 27 '13 at 00:41
  • @Rapptz: Oops, you're right. Anyway, the comments mention the emplace proposal papers. spec changes: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2642.pdf and motivation: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2345.pdf and the second one clearly states that the intent was for emplace_back to _replace_ push_back, and that push_back should be removed. – Mooing Duck Jul 27 '13 at 00:44
  • @Rapptz you are right, I specifically mentioned the stuff you noticed after reading that Q, and not getting much out of it :) – NoSenseEtAl Jul 27 '13 at 01:54
  • dafuq... this q is not a duplicate... that Q is totaly unrelated to this, aka would you close a Q on when to use SP and when to use UP because somebody already A a Q on implementation of unique_ptr and shared_ptr... – NoSenseEtAl Jul 27 '13 at 19:43

1 Answers1

3

emplace_back() only really makes sense when you have to construct the object from scratch just before you put it into the container. If you hand it a pre-constructed object it basically degrades into push_back(). You'll mostly see a difference if the object is expensive to copy or you have to create a lot of them in a tight loop.

I tend to replace the following code:

myvector.push_back(ContainedObject(hrmpf));

with

myvector.emplace_back(hrmpf);

if the former shows up on the profiler output. For new code, I'll probably use emplace_back if I can (we still mainly us VS2010 at work and its implementation of emplace_back() is a bit hobbled).

Timo Geusch
  • 24,095
  • 5
  • 52
  • 70
  • Why do you say emplace_back doesn't make sense in other situations? – Mooing Duck Jul 27 '13 at 00:36
  • @MooingDuck because `push_back` is already overloaded on rvalue references, so if you already have an object, you can just move it into the vector, rather than to construct it in-place, as `emplace_back` would – TemplateRex Jul 27 '13 at 06:56
  • @TemplateRex: Ah, you're saying it doesn't make sense because we already have `push_back`. I would argue the other way, that `emplace_back` _always_ makes sense, and that `push_back` is deprecated. – Mooing Duck Jul 27 '13 at 18:03
  • 1
    @MooingDuck What I'm saying is that the essential difference is the moment of construction. If you don't control object construction, and are being handed a bunch of already created objects to be stored in a container, you use `push_back()` (and you can either copy or move them). If you control construction, you can directly construct the object in place using `emplace_back()`. Saying that `push_back()` is deprecated, narrows your design space to the point where multi-layer frameworks (network-based message passing, anyone?) are more or less excluded. – TemplateRex Jul 27 '13 at 21:07