Is it a premature optimization to use std::move()?

Question

Suppose I have the following code:

int main() {     std::vector<std::string> strs;      std::string var("Hello World");     // Make some modifications to 'var'     strs.push_back(std::move(var)); } 

The part of the sample I want to point out is the usage of std::move(). Basically I'm worried about a copy on the push_back() call. Suppose the string I'm adding is really big. I'm still learning C++11 r-value references, so I'm not sure how the compiler would optimize away the copy (if at all) without the std::move().

Could anyone explain if this is a premature optimization (forcing moves in all cases where you want to avoid copies, in general)? If so, what patterns should I expect the compiler to follow (or most likely follow) that would result in an optimized and automatic move here?

EDIT

I want to add that I understand how automatic moves happen on function return values, because NRVO/RVO applies. The specific example I gave here wouldn't apply RVO, so I'm uncertain.

Answer 1

I'm not sure how the compiler would optimize away the copy (if at all) without the std::move().

Only a very clever compiler could optimise that away, so if the copy could be expensive (e.g. a very long string) then it is better to move it.

Without the move the code is effectively a sequences of calls to:

strlen  // count "Hello World" malloc  // allocate memory for string var strcpy  // copy data into var malloc  // re-allocate vector free    // deallocate old vector malloc  // allocate new string strcpy  // copy from var to new string free    // destroy var 

With the move it becomes:

strlen  // count "Hello World" malloc  // allocate memory for string var strcpy  // copy data into var malloc  // re-allocate vector free    // deallocate old vector 

In theory a smart compiler could do that transformation automatically, but for the compiler to see through all the layers of abstraction introduced by the constructors and destructor and the vector member functions is quite difficult, so proving that the code could be transformed to remove a malloc and free is complicated.

Answer 2

The other answers focus too much on the technical aspects of the question for my taste, so I will try to give a more general answer.

In short: No, using a "trick" like std::move in the way it's described in the question isn't a premature optimization. Not using std::move when it can be used is fine too, unless the code is already known to be performance critical.

The need to avoid premature optimization is sometimes understood as "don't optimize, until you can prove it's necessary", but I prefer to read it as: "don't waste time solving problems unless you know they need to be solved".

Premature optimizations require spending effort in order to optimize what may not need to be optimized, and usually transform a simple problem into a complex problem while doing so. From that perspective, I would classify any long pondering of the question itself as premature optimization.

A related example: People working in performance critical code will often pass arguments as const references ( const std::string& ). Because that's what they are used to do, they will use the same pattern in code that isn't performance critical, even though they could just use pass-by-copy ( const std::string, or even std::string ). That isn't a premature optimization either.