Capturing a reference by reference in a C++11 lambda

by

The code is guaranteed to work.

Before we delve into the standards wording: it’s the C++ committee’s intent that this code works. However, the wording as it stands was believed to be insufficiently clear on this (and indeed, bugfixes made to the standard post-C++14 broke the delicate arrangement that made it work), so CWG issue 2011 was raised to clarify matters, and is making its way through the committee now. As far as I know, no implementation gets this wrong.

I’d like to clarify a couple of things, because Ben Voigt’s answer contains some factual errors that are creating some confusion:

  1. “Scope” is a static, lexical notion in C++, that describes a region of the program source code in which unqualified name lookup associates a particular name with a declaration. It has nothing to do with lifetime. See [basic.scope.declarative]/1.

  2. The “reaching scope” rules for lambdas are, likewise, a syntactic property that determine when capture is permitted. For example:

    void f(int n) {
  struct A {
    void g() { // reaching scope of lambda starts here
      [&] { int k = n; };
      // ...

    n is in scope here, but the reaching scope of the lambda does not include it, so it cannot be captured. Put another way, the reaching scope of the lambda is how far “up” it can reach and capture variables — it can reach up to the enclosing (non-lambda) function and its parameters, but it can’t reach outside that and capture declarations that appear outside.

So the notion of “reaching scope” is irrelevant to this question. The entity being captured is make_function‘s parameter x, which is within the reaching scope of the lambda.

OK, so let’s look at the standard’s wording on this issue. Per [expr.prim.lambda]/17, only id-expressions referring to entities captured by copy are transformed into a member access on the lambda closure type; id-expressions referring to entities captured by reference are left alone, and still denote the same entity they would have denoted in the enclosing scope.

This immediately seems bad: the reference x‘s lifetime has ended, so how can we refer to it? Well, it turns out that there is almost (see below) no way to refer to a reference outside its lifetime (you can either see a declaration of it, in which case it’s in scope and thus presumably OK to use, or it’s a class member, in which case the class itself must be within its lifetime for the member access expression to be valid). As a result, the standard did not have any prohibitions on using a reference outside its lifetime until very recently.

The lambda wording took advantage of the fact that there is no penalty for using a reference outside its lifetime, and so didn’t need to give any explicit rules for what access to an entity captured by reference means — it just means you use that entity; if it’s a reference, the name denotes its initializer. And that’s how this was guaranteed to work up until very recently (including in C++11 and C++14).

However, it’s not quite true that you can’t mention a reference outside its lifetime; in particular, you can reference it from within its own initializer, from the initializer of a class member earlier than the reference, or if it is a namespace-scope variable and you access it from another global that is initialized before it is. CWG issue 2012 was introduced to fix that oversight, but it inadvertantly broke the specification for lambda capture by reference of references. We should get this regression fixed before C++17 ships; I’ve filed a National Body comment to make sure it’s suitably prioritized.

More Related Contents:

  1. A positive lambda: ‘+[]{}’ – What sorcery is this? [duplicate]
  2. Lambda capture and parameter with same name – who shadows the other? (clang vs gcc)
  3. Can using a lambda in header files violate the ODR?
  4. reinterpret_cast creating a trivially default-constructible object
  5. Is it a conforming compiler extension to treat non-constexpr standard library functions as constexpr?
  6. Why does C++11’s lambda require “mutable” keyword for capture-by-value, by default?
  7. How to capture a unique_ptr into a lambda expression?
  8. When is a private constructor not a private constructor?
  9. Is constexpr supported with lambda functions / expressions?
  10. The simplest and neatest c++11 ScopeGuard
  11. Using member variable in lambda capture list inside a member function
  12. Why are lambda expressions not allowed in an unevaluated operands but allowed in the unevaluated portions of constant expressions?
  13. Do I really need to implement user-provided constructor for const objects?
  14. Capturing perfectly-forwarded variable in lambda
  15. Is std::abs(0u) ill-formed?
  16. Why does the standard differentiate between direct-list-initialization and copy-list-initialization?
  17. What does the void() in decltype(void()) mean exactly?
  18. Can the point-of-instantiation be delayed until the end of the translation unit?
  19. C++11 “overloaded lambda” with variadic template and variable capture
  20. Is a constexpr array necessarily odr-used when subscripted?
  21. Is the Empty Base Class Optimization now a mandatory optimization (at least for standard-layout classes)?
  22. What is the lifetime of a C++ lambda expression?
  23. Classes with both template and non-template conversion operators in the condition of switch statement
  24. reinterpret_cast between char* and std::uint8_t* – safe?
  25. Does C++11 change the behavior of explicitly calling std::swap to ensure ADL-located swap’s are found, like boost::swap?
  26. how to specify vc11 lambda calling convention
  27. Proper way to receive a lambda as parameter by reference
  28. When to use functors over lambdas
  29. Why can’t C++11 move a noncopyable functor to a std::function?
  30. Using Boost adaptors with C++11 lambdas

Leave a Comment