I'm a bit confused regarding the difference between push_back and emplace_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 of emplace_back becomes?
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 semantics bring to the table, there are 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.
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)); –
Untie emplace_back so long as it was implemented into Visual C++ when variadic templates were added: msdn.microsoft.com/en-us/library/hh567368.aspx –
Pushover std::piecewise; there are only the type std::piecewise_construct_t and the global instance thereof std::piecewise_construct. –
Agonizing 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
s in scope, isn't that dangerous ? –
Solita vec.emplace_back("Hello") will work, since the const char* argument will be forwarded to the string constructor. This is the whole point of emplace_back. –
Transmundane vec.emplace_back(std::string("Hello")) will also prevent the default string constructor from being called. –
Quern std::vector. An empty std::vector is a valid state, but you cannot call front() on it. This means that any function that has no preconditions can still be called (and destructors can never have preconditions). –
Stark Optimization for emplace_back can be demonstrated in following example.
For emplace_back, constructor A (int x_arg) will be called.
For push_back, A (int x_arg) is called first and move A (A &&rhs) is called afterward.
Of course, the constructor has to be marked as explicit, but for the current example, it 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 &&)
v.emplace_back(x); where x is explicitly move-constructable but only explicitly copy-constructable. The fact that emplace_back is "implicitly" explicit makes me think that my go-to function for appending should probably be push_back. Thoughts? –
Satisfied a.emplace_back second time, the move constructor will be called! –
Slambang "A (A &&)\n", print "A (A &&) on " << rhs.x << "\n". You can see it in this edited code snippet. –
Actionable 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 for emplace_back would be more
performant than constructing and then moving the object (which generally involves some copying).emplace_back instead of push_back in all the cases without much issue. (See exceptions)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"});
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. –
Prolix A nice code for the push_back and emplace_back is shown here.
http://en.cppreference.com/w/cpp/container/vector/emplace_back
You can see the move operation on push_back and not on emplace_back.
emplace_back conforming implementation will forward arguments to the vector<Object>::value_typeconstructor when added to the vector. I recall Visual Studio didn't support variadic templates, but with variadic templates will be supported in Visual Studio 2013 RC, so I guess a conforming signature will be added.
With emplace_back, if you forward the arguments directly to vector<Object>::value_type constructor, you don't need a type to be movable or copyable for emplace_back function, strictly speaking. In the vector<NonCopyableNonMovableObject> case, this is not useful, since vector<Object>::value_type needs a copyable or movable type to grow.
But note that this could be useful for std::map<Key, NonCopyableNonMovableObject>, since once you allocate an entry in the map, it doesn't need to be moved or copied ever anymore, unlike with vector, meaning that you can use std::map effectively with a mapped type that is neither copyable nor movable.
© 2022 - 2024 — McMap. All rights reserved.
template <class _Valty> void emplace_back(_Valty&& _Val)version that takes a universal reference which provides perfect forwarding toexplicitsingle argument constructors. – Quibblingpush_backis 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. – Satisfiedemplace_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. – Agonizingemplace_backwill "implicitly" callexplicitconstructors, which could lead to undesired behavior. (For heavy classes, I often make the copy c'torexplicitleaving 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)).) – Satisfied