Copy-elision of automatic variable for return

I am wondering if in C++0x "12.8 C开发者_如何学Copying and Moving class objects [class.copy] paragraph 31" when copy elision happens, exactly:

When certain criteria are met, an implementation is allowed to omit the copy/move construction of a class object [...]. This elision of copy/move operations, called copy elision, is permitted in the following circumstances [...]:

• in a return statement in a function with a class return type, when the expression is the name of a non-volatile automatic object [...] with the same cv-unqualified type as the function return type, the copy/move operation can be omitted by constructing the automatic object directly into the function’s return value
• [...]

And now I wonder, if this allows in the following code to elude copy

vector<string> gen(const char *fn) {
    if(fn == nullptr)  // this should prevent RVO
        return {"House", "Horse", "Hen"};
    vector<string> res;
    fillFromFile(res, fn);
    return res;  // copy elision possible?
}
int main() {
    vector<string> data = gen("users.dat");
}

Or does that rule not fot the example, and I have to do it explicit?

    return move(res);  // explicitly prevent copy

Note that my intention of the if was to eliminate the obvious Return Value Optimization (RVO).

Or am I completely on the wrong track here? There was a change involving return and move that could use rvalue references, right?

---

Yes, copy elision is possible/allowed in both cases.

In compiler terminology, the two cases are slightly different though. return {"House", "Horse", "Hen"}; constructs an unnamed object, so regular RVO kicks in.

return res; is slightly more complex, because you are returning a named object which was already constructed earlier. This optimization is typically called NRVO (Named Return Value Optimization), and it is slightly less common for compilers to implement it.

MSVC always implements RVO, and performs NRVO in release builds.

I believe recent versions of GCC always perform both RVO and NRVO.

By the way, I don't really see why your ´if` would make a difference for RVO.

---

Yes, the compiler has specific instructions to treat res like an rvalue in this context, and res will be moved into data. Of course, the compiler could easily apply RVO/NRVO here anyway because it can statically determine that you never call the function with nullptr, and in addition, the function could be trivially transformed so that RVO/NRVO can be applied even if that couldn't be proven, and finally, that doesn't even prevent RVO/NRVO as the result can still be constructed in.