Reputation: 4565
Is below code standard-correct? (godbolt)
I.e. by-ref capturing a forwarding reference that represents a temporary, and returning the resulting lambda by-value from the function, within the same expression.
Of course storing the lambda for later use would make it contain a dangling reference, but I'm referring to the exact usage inside main
.
The doubts I'm having relate to this SO answer and potentially this language defect. Specifically there is one daunting comment that says "the reference capture lifetime rule in the standard references captured variables, not data, and their scope" - this appears to say a captured reference to a temporary might be invalid in my code.
#include <stdlib.h>
#include <string.h>
#include <cassert>
template<typename F>
auto invoke(F&& f)
{
return f();
}
template<typename F>
auto wrap(F&& f)
{
return [&f]() {return f();}; // <- this by-ref capture here
}
int main()
{
int t = invoke(wrap(
[]() {return 17;}
));
assert(t == 17);
return t;
}
Upvotes: 7
Views: 1989
Reputation: 188
In the expression
int t = invoke(wrap(
[]() {return 17;}
));
my understanding is:
[]() {return 17;}
is a nameless temporary, but let's name it λ ourselves.C
be its closure type.wrap
template called will be wrap<C>(C&& f)
.f
, which has an (rvalue) reference type.wrap
; it captures parameter f
by reference.f
refers to λ (rather than to the parameter of wrap
, which is distinct but also shares the name f
), and this should be the crucial distinction (highlited by the defect report).f
will end once wrap
returns, but within Λ f
is not dangling because it refers to λ, and the lifetime of λ is the full expression (which ends with the semicolon in the declaration of int t
).wrap
is a nameless temporary and thus an rvalue.K
be its closure type.invoke
template called will be hence invoke<K>(K&& f)
and Λ is bound to the parameter f
, which has (rvalue) reference type.f
is called from within invoke
, which calls operator()
from Λ.f
within the body of Λ refers to λ (whose lifetime has not expired: we're still in the full expression that created the nameless temporary λ), and no UB happens.Upvotes: 0
Reputation: 275976
There was UB in your code for a relatively short historical time window. (Note: this is a very strange thing to say). The original lambda capture-by-reference rules stated the reference was only valid until the variable captured went out of scope.
There is no UB in your code under both the current standard, and under every retroactively revised past standards.
This could lead to a sort of capture reference-by-reference, otherwise impossible in the C++ standard. (The closest you could get would be a reference to a one-member struct containing a reference)
In theory, you could use that fact to make lambda reference capture be stack-frame based; capture the current stack frame, and all (almost?) by-reference arguments would be at fixed offsets to that stack frame.
As most (all?) ABIs implement reference arguments as pointers under the hood, this would lead to reference arguments to functions arguments which are references dangling after the lambda returned.
No compiler exploited this fact. That optimization was never used, it was just observed as possible. The "reference capture of a lambda has a lifetime of the variable reference" rule was never exploited by any compiler (or at least any I heard of).
When it was spotted, it was resolved as a defect resolution in the standard, which means it retroactively redefined what c++11 meant.
So while under historical c++11 compiler this was technically UB, no current compliant c++11 compiler can treat it as UB, and all historical C++11 compilers treat it the same way current compilers do. So you are safe.
Upvotes: 11
Reputation: 49028
Yes there is no UB in your code. f
is bound to the lambda, but you invoke the lambda which captures f
in the same expression, so its lifetime has not ended. The defect report you linked clarifies what capturing a reference by reference means. It was resolved by clarifying that the reference capture is actually a reference to the object the captured reference is bound to.
In your case, the captured f
is a reference to the lambda (instead of to the parameter f
).
Upvotes: 2