When working with std::vector in C++, you'll often need to add elements to the end. Two common methods are push_back and emplace_back. While both achieve the same result – adding an element – they differ significantly in their underlying mechanisms, impacting performance and code clarity. This article will dissect these differences, drawing upon insights from Stack Overflow and enhancing them with practical examples and explanations.
Understanding the Core Difference
The key distinction lies in how each function handles object creation.
push_back: This function takes an element by value or by rvalue reference. It receives a fully constructed object and then copies (or moves, if using an rvalue reference) that object into the vector.
emplace_back: This function takes arguments by value, using perfect forwarding to construct the object directly within the vector's allocated memory. It avoids the creation of a temporary object.
Let's illustrate this with a Stack Overflow-inspired example (although I'll adapt and expand it for clarity):
A common question on Stack Overflow revolves around the performance differences. While a simple example might not show a huge difference, the impact becomes significant with complex objects. Imagine a class like this:
#include <vector>
#include <iostream>
#include <chrono>
class ExpensiveObject {
public:
ExpensiveObject(int data) : data_(data) {
std::cout << "ExpensiveObject constructor called\n";
// Simulate expensive operation
for (int i = 0; i < 1000000; ++i);
}
ExpensiveObject(const ExpensiveObject& other) : data_(other.data_) {
std::cout << "ExpensiveObject copy constructor called\n";
}
ExpensiveObject(ExpensiveObject&& other) noexcept : data_(other.data_) {
std::cout << "ExpensiveObject move constructor called\n";
other.data_ = -1; // indicate moved-from state.
}
~ExpensiveObject() { std::cout << "ExpensiveObject destructor called\n"; }
int getData() const { return data_; }
private:
int data_;
};
Now, let's compare push_back and emplace_back:
int main() {
std::vector<ExpensiveObject> vec1;
auto start = std::chrono::high_resolution_clock::now();
for (int i = 0; i < 1000; ++i) {
vec1.push_back(ExpensiveObject(i)); // Copy construction is used here
}
auto end = std::chrono::high_resolution_clock::now();
auto duration = std::chrono::duration_cast<std::chrono::microseconds>(end - start);
std::cout << "push_back took " << duration.count() << " microseconds\n";
std::vector<ExpensiveObject> vec2;
start = std::chrono::high_resolution_clock::now();
for (int i = 0; i < 1000; ++i) {
vec2.emplace_back(i); // Direct construction in place
}
end = std::chrono::high_resolution_clock::now();
duration = std::chrono::duration_cast<std::chrono::microseconds>(end - start);
std::cout << "emplace_back took " << duration.count() << " microseconds\n";
return 0;
}
Running this code will clearly demonstrate that emplace_back is significantly faster. The output shows that emplace_back avoids the costly copy construction (or even move construction if you had a move constructor available that didn't cost anything).
When to Use Which?
push_back: Use when you already have a fully constructed object and want to add it to the vector. This might be the case if you're receiving objects from another function.emplace_back: Use whenever possible for adding new elements, particularly with complex objects. This avoids unnecessary temporary object creation and copying/moving, leading to better performance and potentially less memory allocation.
Conclusion
While seemingly subtle, the difference between push_back and emplace_back is crucial for performance optimization, especially when dealing with complex or expensive-to-construct objects. Understanding this distinction allows for writing more efficient and elegant C++ code, informed by best practices shared and discussed extensively within the Stack Overflow community. Always prioritize emplace_back unless you have a specific reason to use push_back. Remember that the performance gains are most noticeable with complex objects where copy or move constructors are relatively expensive. For simpler types, the difference might be negligible.