I am writing library which wraps a lot of functions and methods from other library. To avoid coping of return values I am applying std::forward
like so:
Depending on what this function gets passed, it results in undefined behavior! More precisely, if you pass a non-lvalue, i.e. an rvalue, to this function, the value referenced by the returned reference will be stale.
Also T&&
isn't a "universal reference" although the effect is somewhat like a universal reference in that T
can be deduced as T&
or T const&
. The problematic case is when it gets deduced as T
: the arguments get passed in as temporary and die after the function returns but before anything can get hold of a reference to it.
The use of std::forward
is limited to, well, forwarding objects when calling another function: what came in as a temporary looks like an lvalue within the function. Using std::forward
lets x
look like a temporary if it came in as one - and, thus, allow moving from x
when creating the argument of the called function.
When you return an object from a function there are a few scenarios you might want to take care of but none of them involves std::forward()
:
const
or non-const
, you don't want to do anything with the object and just return the reference.return
statements use the same variable or all are using a temporary, copy/move elision can be used and will be used on decent compilers. Since the copy/move elision is an optimization, it doesn't necessarily happen, however.std::move()
to allow moving from the local object.In most of these cases the produced type is T
and you should return T
rather than T&&
. If T
is an lvalue type the result may not be an lvalue type, though, and it may be necessary to remove the reference qualification from the return type. In the scenario you specifically asked about the type T
works.