Guaranteed copy elision in C++17 and emplace_back(…)

Question

emplace_back(...) was introduced with C++11 to prevent the creation of temporary objects. Now with C++17 pure lvalues are even purer so that they do not lead to the creation of temporaries anymore (see this question for more). Now I still do not fully understand the consequences of these changes, do we still need emplace_back(...) or can we just go back and use push_back(...) again?

Answer 1

You may see here: std::vector::push_back that this method requires either CopyInsertable or MoveInsertable, also it takes either const T& value or T&& value , so I dont see how elision could be of use here.

The new rules of mandatory copy ellision are of use in the following example:

struct Data {
    Data() {}
    Data(const Data&) = delete;
    Data(Data&&) = delete;
};

Data create() {
    return Data{};  // error before c++17   
}

void foo(Data) {}

int main()
{
    Data pf = create();
    foo(Data{});  // error before c++17
}

so, you have a class which does not support copy/move operations. Why, because maybe its too expensive. Above example is a kind of a factory method which always works. With new rules you dont need to worry if compiler will actually use elision - even if your class supports copy/move.

I dont see the new rules will make push_back faster. emplace_back is still more efficient but not because of the copy ellision but because of the fact it creates object in place with forwarding arguments to it.

Answer 2

Both push_back and emplace_back member functions create a new object of its value_type T at some place of the pre-allocated buffer. This is accomplished by the vector's allocator, which, by default, uses the placement new mechanism for this construction (placement new is basically just a way of constructing an object at a specified place in memory).

However:

• emplace_back perfect-forwards its arguments to the constructor of T , thus the constructor that is the best match for these arguments is selected.
• push_back(T&&) internally uses the move constructor ( if it exists and does not throw ) to initialize the new element. This call of move constructor cannot be elided and is always used.

Consider the following situation:

std::vector<std::string> v;
v.push_back(std::string("hello"));

The std::string 's move constructor is always called here that follows the converting constructor which creates a string object from a string literal. In this case:

v.emplace_back("hello");

there is no move constructor called and the vector's element is initialized by std::string 's converting constructor directly.

---

This does not necessarily mean the push_back is less efficient. Compiler optimizations might eliminate all the additional instructions and finally both cases might produce the exact same assembly code. Just it's not guaranteed.

---

By the way, if push_back passed arguments by value — void push_back(T param); — then this would be a case for the application of copy elision. Namely, in:

v.push_back(std::string("hello"));

the parameter param would be constructed by a move-constructor from the temporary. This move-construction would be a candidate for copy elision. However, this approach would not at all change anything about the mandatory move-construction for vector's element inside push_back body.