CODEWITHSUNDEEP
c++lambdatemporary-objectsforwarding-reference
haelix
haelix

Reputation: 4565

Lambda capturing rvalue reference by reference

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

Answers (3)

Fimpellizzeri
Fimpellizzeri

Reputation: 188

In the expression

int t = invoke(wrap(
    []() {return 17;}
));

my understanding is:

  1. The lambda []() {return 17;} is a nameless temporary, but let's name it λ ourselves.
    Let C be its closure type.
  2. λ is an rvalue and hence the wrap template called will be wrap<C>(C&& f).
    λ is bound to the parameter f, which has an (rvalue) reference type.
  3. Let Λ be the lambda in wrap; it captures parameter f by reference.
    Within a lambda, a reference captured by reference refers to the object referred by the captured reference (rather than to the captured reference itself).
    In other words, within the body of Λ, 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).
    The lifetime of the rvalue reference parameter 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).
  4. Λ returned by wrap is a nameless temporary and thus an rvalue.
    Similarly as before, let K be its closure type.
    The invoke template called will be hence invoke<K>(K&& f) and Λ is bound to the parameter f, which has (rvalue) reference type.
  5. f is called from within invoke, which calls operator() from Λ.
    As we saw in (3), the usage of 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

Yakk - Adam Nevraumont
Yakk - Adam Nevraumont

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 meant.

So while under historical compiler this was technically UB, no current compliant 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

Rakete1111
Rakete1111

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

Related Questions