Copy-elision of automatic variable for return

Question

I am wondering if in C++0x "12.8 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?

score 3 · Accepted Answer · answered Apr 24 '11 at 13:29

3

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.

answered Apr 24 '11 at 13:29

jalf

243,077
51
345
550

The term NRVO is new to me. But this was `RVO`able before: If I construct an object once (by giving it a name) and fill it in different paths but *always* return that pre-constructed named object -- then RVO kicks in. No need to copy and no news *there*, right? – towi Apr 24 '11 at 13:49
I doubt the second case. As mentioned in the question, the if condition should prevent all forms of RVO. – balki Apr 26 '11 at 06:29
@balki: why? I don't see anything in the quoted text that would prohibit it. – jalf Apr 26 '11 at 07:01

score 0 · Answer 2 · answered Apr 24 '11 at 13:30

0

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.

answered Apr 24 '11 at 13:30

Puppy

144,682
38
256
465

Ok, `main` was not a good example here. Obviously the compiler can eliminate half my program :-) But providing two paths, with two completly different returns... is this then *new* because the `return res` can consider `res` to be a rval-ref, and thus, apply a move? – towi Apr 24 '11 at 13:53

Copy-elision of automatic variable for return

2 Answers2