push_back vs emplace_back
Solution 1
In addition to what visitor said :
The function void emplace_back(Type&& _Val)
provided by MSCV10 is non conforming and redundant, because as you noted it is strictly equivalent to push_back(Type&& _Val)
.
But the real C++0x form of emplace_back
is really useful: void emplace_back(Args&&...)
;
Instead of taking a value_type
it takes a variadic list of arguments, so that means that you can now perfectly forward the arguments and construct directly an object into a container without a temporary at all.
That's useful because no matter how much cleverness RVO and move semantic bring to the table there is still complicated cases where a push_back is likely to make unnecessary copies (or move). For example, with the traditional insert()
function of a std::map
, you have to create a temporary, which will then be copied into a std::pair<Key, Value>
, which will then be copied into the map :
std::map<int, Complicated> m;
int anInt = 4;
double aDouble = 5.0;
std::string aString = "C++";
// cross your finger so that the optimizer is really good
m.insert(std::make_pair(4, Complicated(anInt, aDouble, aString)));
// should be easier for the optimizer
m.emplace(4, anInt, aDouble, aString);
So why didn't they implement the right version of emplace_back in MSVC? Actually, it bugged me too a while ago, so I asked the same question on the Visual C++ blog. Here is the answer from Stephan T Lavavej, the official maintainer of the Visual C++ standard library implementation at Microsoft.
Q: Are beta 2 emplace functions just some kind of placeholder right now?
A: As you may know, variadic templates aren't implemented in VC10. We simulate them with preprocessor machinery for things like
make_shared<T>()
, tuple, and the new things in<functional>
. This preprocessor machinery is relatively difficult to use and maintain. Also, it significantly affects compilation speed, as we have to repeatedly include subheaders. Due to a combination of our time constraints and compilation speed concerns, we haven't simulated variadic templates in our emplace functions.When variadic templates are implemented in the compiler, you can expect that we'll take advantage of them in the libraries, including in our emplace functions. We take conformance very seriously, but unfortunately, we can't do everything all at once.
It's an understandable decision. Everyone who tried just once to emulate variadic template with preprocessor horrible tricks knows how disgusting this stuff gets.
Solution 2
emplace_back
shouldn't take an argument of type vector::value_type
, but instead variadic arguments that are forwarded to the constructor of the appended item.
template <class... Args> void emplace_back(Args&&... args);
It is possible to pass a value_type
which will be forwarded to the copy constructor.
Because it forwards the arguments, this means that if you don't have rvalue, this still means that the container will store a "copied" copy, not a moved copy.
std::vector<std::string> vec;
vec.emplace_back(std::string("Hello")); // moves
std::string s;
vec.emplace_back(s); //copies
But the above should be identical to what push_back
does. It is probably rather meant for use cases like:
std::vector<std::pair<std::string, std::string> > vec;
vec.emplace_back(std::string("Hello"), std::string("world"));
// should end up invoking this constructor:
//template<class U, class V> pair(U&& x, V&& y);
//without making any copies of the strings
Solution 3
Optimization for emplace_back
can be demonstrated in next example.
For emplace_back
constructor A (int x_arg)
will be called. And for
push_back
A (int x_arg)
is called first and move A (A &&rhs)
is called afterwards.
Of course, the constructor has to be marked as explicit
, but for current example is good to remove explicitness.
#include <iostream>
#include <vector>
class A
{
public:
A (int x_arg) : x (x_arg) { std::cout << "A (x_arg)\n"; }
A () { x = 0; std::cout << "A ()\n"; }
A (const A &rhs) noexcept { x = rhs.x; std::cout << "A (A &)\n"; }
A (A &&rhs) noexcept { x = rhs.x; std::cout << "A (A &&)\n"; }
private:
int x;
};
int main ()
{
{
std::vector<A> a;
std::cout << "call emplace_back:\n";
a.emplace_back (0);
}
{
std::vector<A> a;
std::cout << "call push_back:\n";
a.push_back (1);
}
return 0;
}
output:
call emplace_back:
A (x_arg)
call push_back:
A (x_arg)
A (A &&)
Solution 4
One more example for lists:
// constructs the elements in place.
emplace_back("element");
// creates a new object and then copies (or moves) that object.
push_back(ExplicitDataType{"element"});
Solution 5
Specific use case for emplace_back
: If you need to create a temporary object which will then be pushed into a container, use emplace_back
instead of push_back
. It will create the object in-place within the container.
Notes:
-
push_back
in the above case will create a temporary object and move it into the container. However, in-place construction used foremplace_back
would be more performant than constructing and then moving the object (which generally involves some copying). - In general, you can use
emplace_back
instead ofpush_back
in all the cases without much issue. (See exceptions)
ronag
Master of Science (M.Sc.), Software Engineering and Technology at Chalmers University of Technology. I wrote most of CasparCG 2.0 Server, an open-source video- and graphics playout server used by the Swedish Broadcasting Corporation 24/4 for all regional and national broadcasts in Sweden. Big fan of the ffmpeg project.
Updated on August 02, 2022Comments
-
ronag almost 2 years
I'm a bit confused regarding the difference between
push_back
andemplace_back
.void emplace_back(Type&& _Val); void push_back(const Type& _Val); void push_back(Type&& _Val);
As there is a
push_back
overload taking a rvalue reference I don't quite see what the purpose ofemplace_back
becomes?-
Johan Kotlinski over 13 yearsSome good reading here: open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2642.pdf
-
me22 over 13 yearsNote that (as Thomas says below), the code in the question is from MSVS's emulation of C++0x, not what C++0x actually is.
-
Alan about 11 yearsA better paper to read would be: open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2345.pdf. N2642 is mostly wording for the Standard; N2345 is the paper that explains and motivates the idea.
-
joki almost 7 yearsNote that even in MSVC10 there is a
template <class _Valty> void emplace_back(_Valty&& _Val)
version that takes a universal reference which provides perfect forwarding toexplicit
single argument constructors. -
Ben almost 6 yearsRelated: Is there any case where
push_back
is preferable toemplace_back
? The only case I can think of is if a class were somehow copyable (T&operator=(constT&)
) but not construct-able (T(constT&)
), but I can't think of why one would ever want that. -
Albert over 5 yearsAlso see this.
-
underscore_d over 5 years@Ben Everyone else (if I may presume) interprets an unqualified "copyable" to mean copy-constructible, not copy-assignable as you showed. Both
emplace_back()
andpush_back()
will invoke the copy-constructor - i.e. both perform construction, i.e. neither perform assignment - so your suggested class would not fare any better with either. -
Ben over 4 yearsThe related case I tripped over (that I mentioned just now in a separate thread on this page) is that
emplace_back
will "implicitly" callexplicit
constructors, which could lead to undesired behavior. (For heavy classes, I often make the copy c'torexplicit
leaving the move-c'tor implicit.v.emplace_back(x)
bit me by doing basicallyv.emplace_back(X(x))
when I hoped it to error and force me to writev.push_back(std::move(x))
.) -
Gabriel Staples over 4 yearsExcellent and easy-to-understand answer here: quora.com/…
-
Gabriel Staples over 3 years
-
-
David over 13 yearsYou would need to use vec.emplace_back(std::move(s)); since s is an lvalue to get the move behavior
-
Matthieu M. over 13 years@David: but then you have a moved
s
in scope, isn't that dangerous ? -
David over 13 yearsIt's not dangerous if you don't plan on using s any longer for its value. Moving does not make s invalid, the move will only steal the internal memory allocation already done in s and leave it in a defaulted state (no sting allocated) which when destructed will be fine as if you had just typed std::string str;
-
Ben Voigt over 13 years@David: I'm not sure that a moved-from object is required to be valid for any use except subsequent destruction.
-
me22 over 13 yearsThat clarification that it's a MSVS10 issue, not a C++ issue is the most important part here. Thanks.
-
Alexandre C. over 12 years
vec.emplace_back("Hello")
will work, since theconst char*
argument will be forwarded to thestring
constructor. This is the whole point ofemplace_back
. -
lurscher over 12 yearsvisitor, you are dead wrong, please read Alexandre C. comment and Thomas answer
-
DRayX about 12 years
vec.emplace_back(std::string("Hello"))
will also prevent the default string constructor from being called. -
David Stone almost 12 years@BenVoigt: A moved-from object is required to be in a valid (but unspecified) state. This doesn't necessarily mean you can perform any operation on it, however. Consider
std::vector
. An emptystd::vector
is a valid state, but you cannot callfront()
on it. This means that any function that has no preconditions can still be called (and destructors can never have preconditions). -
sellibitze about 11 yearsI believe your last line of C++ code won't work.
pair<const int,Complicated>
does not have a constructor that takes an int, another int, a double and as 4th parameter a string. However, you can directly construct this pair object using its piecewise-constructor. The syntax will be different, of course:m.emplace(std::piecewise,std::forward_as_tuple(4),std::forward_as_tuple(anInt,aDouble,aString));
-
Daniel Earwicker almost 11 yearsHappily variadic templates will be in VS2013, now in preview.
-
becko about 10 yearsshould this answer be updated to reflect the new developments in vs2013?
-
underscore_d over 8 yearssorry, but -1 for what @sellibitze said; it was the same compilation error that brought me here looking for help, but all we get is a false statement that the quoted syntax will work (it doesn't). the rest of the text is merely ok. with these 2 things, i dunno why this got upvoted so far.
-
underscore_d over 8 yearswhy spend 2/3rds of the answer dwelling on the extremely mundane 'emplace is bad for use-cases that aren't the ones for which it was designed', relegating the actual rationale to a "probably" afterthought?
-
kayleeFrye_onDeck almost 7 yearsIf you're using Visual Studio 2013 or later now, you should have support for the "real"
emplace_back
so long as it was implemented into Visual C++ when variadic templates were added: msdn.microsoft.com/en-us/library/hh567368.aspx -
underscore_d over 5 years@sellibitze but then you made a mistake while correcting Thomas's mistake... There is no
std::piecewise
; there are only the typestd::piecewise_construct_t
and the global instance thereofstd::piecewise_construct
. -
Ben over 4 yearsI came here after noticing that I had code that was calling
v.emplace_back(x);
where x is explicitly move-constructable but only explicitly copy-constructable. The fact thatemplace_back
is "implicitly" explicit makes me think that my go-to function for appending should probably bepush_back
. Thoughts? -
kalyanswaroop about 4 yearswith gcc 9.2 m.emplace(4, Complicated(anInt, aDouble, aString)) ; works.
-
Andreas K. almost 4 yearsIf you call
a.emplace_back
second time, the move constructor will be called! -
juztcode almost 4 years@ThomasPetit , what is this MSCV10
-
Mr Nobody over 3 yearsdoes it mean emplace_back does not create a copy ? It just stores the actual object. if we change the object itself after emplace_back , the object in vector should also change ,right?
-
unrealsoul007 almost 3 yearsI think Thomas meant to write, MSVC10 = MicroSoft Visual C++ 10.
-
Brambor over 2 years@AndreasK. That's not related to emplace_back but rather expanding the size of the vector. You can check that by printing what is being moved rather than just
"A (A &&)\n"
, print"A (A &&) on " << rhs.x << "\n"
. You can see it in this edited code snippet. -
ABaumstumpf about 2 years@MrNobody with
emplace_back
it is the container that forwards the arguments to the constructor - aka neither before nor after that call do you have any object at hand. what do you mean by "change the object itself"? There is ONLY the object in the container. Or you create the object beforehand - in which case it acts the same as push_back.