Can I ensure RVO for reintrepret-cast'ed values? - c++

Question

Suppose I've written:
Foo get_a_foo() {
return reinterpret_cast<Foo>(get_a_bar());
}
and suppose that sizeof(Foo) == sizeof(Bar).
Does return value optimization necessarily take place here, or are compilers allowed to do whatever they like when I "break the rules" by using a reinterpret_cast? If I don't get RVO, or am not guaranteed it - can I change this code to ensure that it occur?
My question is about C++11 and, separately, C++17 (since there was some change in it w.r.t. RVO, if I'm not mistaken).

Answer 1

Suppose I've written:
Foo get_a_foo() {
return reinterpret_cast<Foo>(get_a_bar());
}
and suppose that sizeof(Foo) == sizeof(Bar).
That reinterpret_cast is not legal for all possible Foo and Bar types. It only works for cases where:
Bar is a pointer and Foo is either a pointer or an integer/enum big enough to hold pointers.
Bar is an integer/enum big enough to hold a pointer, and Foo is a pointer.
Bar is an object type and Foo is a reference type.
There are a couple of other cases I didn't cover, but they're either irrelevant (nullptr_t casting) or fall under similar issues for #1 or #2.
See, elision doesn't actually matter when dealing in fundamental types. You can't tell the difference between eliding a copy/move of fundamental types and not eliding it. So is there a conversion there? Is the compiler just using the return value register? That's up to the compiler, via the "as if" rule.
And elision doesn't apply when returning reference types, so #3 is out.
But if Foo and Bar are user-defined object types (or object types other than pointers, integers, or member pointers), the cast is is ill-formed. reinterpret_cast is not some kind of trivial memcpy conversion function.
So let's replace this with some code that could, you know, actually work:
Foo get_a_foo()
{
return std::bit_cast<Foo>(get_a_bar());
}
Where C++20's std::bit_cast effectively converts one trivial copyable type to another trivial copyable type.
That conversion still would not be elided. Or at least, not in the way "elision" is typically used.
Because the two types are trivially copyable, and bit_cast will only call trivial constructors, the compiler could certainly erase the constructors, and even use the return value object of get_a_foo as the return value object of get_a_bar. And thus, it could be considered "elision".
But "elision" typically refers to the part of the standard that allows the implementation to disregard even non-trivial constructor/destructors. The compiler can only perform the above because all of the constructors and destructors are trivial. If they were non-trivial, they could not be disregarded (then again, if they were non-trivial, std::bit_cast wouldn't work).
My point is that the optimization of the conversion above is not due to "elision" or RVO rules; it's due entirely to the "as if" rule. Even in C++17, whether the bit_cast call is effectively made a noop is entirely up to the compiler. Yes, after having created the Foo prvalue, the "elision" of it's copy into the function's return value object is required by C++17.
But the conversion itself is not a matter of elision.