7.16 — Lambda captures

Capture clauses and capture by value

In the previous lesson, we introduced this example:

Now, let’s modify the nut example and let the user pick a substring to search for. This isn’t as intuitive as you might expect.

This code won’t compile. Unlike nested blocks, where any identifier defined in an outer block is accessible in the scope of the nested block, lambdas can only access specific kinds of identifiers: global identifiers, entities that are known at compile time, and entities with static storage duration. search fulfills none of these requirements, so the lambda can’t see it. That’s what the capture clause is there for.

The capture clause

The capture clause is used to (indirectly) give a lambda access to variables available in the surrounding scope that it normally would not have access to. All we need to do is list the entities we want to access from within the lambda as part of the capture clause. In this case, we want to give our lambda access to the value of variable search, so we add it to the capture clause:

The user can now search for an element of our array.


search for: nana
Found banana

So how do captures actually work?

While it might look like our lambda in the example above is directly accessing the value of main‘s search variable, this is not the case. Lambdas might look and function like nested blocks, but they work slightly differently (and the distinction is important).

When a lambda definition is executed, for each variable that the lambda captures, a clone of that variable is made (with an identical name) inside the lambda. These cloned variables are initialized from the outer scope variables of the same name at this point.

Thus, in the above example, when the lambda object is created, the lambda gets its own cloned variable named search. This cloned search has the same value as main‘s search, so it behaves like we’re accessing main‘s search, but we’re not.

While these cloned variable have the same name, they don’t necessarily have the same type as the original variable. We’ll explore this in the upcoming sections of this lesson.

Key insight

The captured variables of a lambda are clones of the outer scope variables, not the actual variables.

For advanced readers

Although lambdas look like functions, they’re actually objects that can be called like functions (these are called functors -- we’ll discuss how to create your own functors from scratch in a future lesson).

When the compiler encounters a lambda definition, it creates a custom object definition for the lambda. Each captured variable becomes a data member of the object.

At runtime, when the lambda definition is encountered, the lambda object is instantiated, and the members of the lambda are initialized at that point.

Captures default to const value

By default, variables are captured by const value. This means when the lambda is created, the lambda captures a constant copy of the outer scope variable, which means that the lambda is not allowed to modify them. In the following example, we capture the variable ammo and try to decrement it.

In the above example, when we capture ammo, a new const variable with the same name and value is created in the lambda. We can’t modify it, because it is const, which causes a compile error.

Mutable capture by value

To allow modifications of variables that were captured by value, we can mark the lambda as mutable. The mutable keyword in this context removes the const qualification from all variables captured by value.


Pew! 9 shot(s) left.
Pew! 8 shot(s) left.
10 shot(s) left

While this now compiles, there’s still a logic error. What happened? When the lambda was called, the lambda captured a copy of ammo. When the lambda decremented ammo from 10 to 9 to 8, it decremented its own copy, not the original value.

Note that the value of ammo is preserved across calls to the lambda!

Capture by reference

Much like functions can change the value of arguments passed by reference, we can also capture variables by reference to allow our lambda to affect the value of the argument.

To capture a variable by reference, we prepend an ampersand (&) to the variable name in the capture. Unlike variables that are captured by value, variables that are captured by reference are non-const, unless the variable they’re capturing is const. Capture by reference should be preferred over capture by value whenever you would normally prefer passing an argument to a function by reference (e.g. for non-fundamental types).

Here’s the above code with ammo captured by reference:

This produces the expected answer:

Pew! 9 shot(s) left.
9 shot(s) left

Now, let’s use a reference capture to count how many comparisons std::sort makes when it sorts an array.


Comparisons: 2
Honda Civic
Toyota Corolla
Volkswagen Golf

Capturing multiple variables

Multiple variables can be captured by separating them with a comma. This can include a mix of variables captured by value or by reference:

Default captures

Having to explicitly list the variables you want to capture can be burdensome. If you modify your lambda, you may forget to add or remove captured variables. Fortunately, we can enlist the compiler’s help to auto-generate a list of variables we need to capture.

A default capture (also called a capture-default) captures all variables that are mentioned in the lambda. Variables not mentioned in the lambda are not captured if a default capture is used.

To capture all used variables by value, use a capture value of =.
To capture all used variables by reference, use a capture value of &.

Here’s an example of using a default capture by value:

Default captures can be mixed with normal captures. We can capture some variables by value and others by reference, but each variable can only be captured once.

Defining new variables in the lambda-capture

Sometimes we want to capture a variable with a slight modification or declare a new variable that is only visible in the scope of the lambda. We can do so by defining a variable in the lambda-capture without specifying its type.

userArea will only be calculated once when the lambda is defined. The calculated area is stored in the lambda object and is the same for every call. If a lambda is mutable and modifies a variable that was defined in the capture, the original value will be overridden.

Best practice

Only initialize variables in the capture if their value is short and their type is obvious. Otherwise it’s best to define the variable outside of the lambda and capture it.

Dangling captured variables

Variables are captured at the point where the lambda is defined. If a variable captured by reference dies before the lambda, the lambda will be left holding a dangling reference.

For example:

The call to makeWalrus creates a temporary std::string from the string literal “Roofus”. The lambda in makeWalrus captures the temporary string by reference. The temporary string dies when makeWalrus returns, but the lambda still references it. Then when we call sayName, the dangling reference is accessed, causing undefined behavior.

Note that this also happens if name is passed to makeWalrus by value. The variable name still dies at the end of makeWalrus, and the lambda is left holding a dangling reference.


Be extra careful when you capture variables by reference, especially with a default reference capture. The captured variables must outlive the lambda.

If we want the captured name to be valid when the lambda is used, we need to capture it by value instead (either explicitly or using a default-capture by value).

Unintended copies of mutable lambdas

Because lambdas are objects, they can be copied. In some cases, this can cause problems. Consider the following code:



Rather than printing 1, 2, 3, the code prints 2 twice. When we created otherCount as a copy of count, we created a copy of count in its current state. count‘s i was 1, so otherCount‘s i is 1 as well. Since otherCount is a copy of count, they each have their own i.

Now let’s take a look at a slightly less obvious example:



This exhibits the same problem as the prior example in a more obscure form. When std::function is created with a lambda, the std::function internally makes a copy of the lambda object. Thus, our call to fn() is actually being executed on the copy of our lambda, not the actual lambda.

If we need to pass a mutable lambda, and want to avoid the possibility of inadvertent copies being made, there are two options. One option is to use a non-capturing lambda instead -- in the above case, we could remove the capture and track our state using a static local variable instead. But static local variables can be difficult to keep track of and make our code less readable. A better option is to prevent copies of our lambda from being made in the first place. But since we can’t affect how std::function (or other standard library functions or objects) are implemented, how can we do this?

Fortunately, C++ provides a convenient type (as part of the <functional> header) called std::ref that allows us to pass a normal type as if it were a reference. By wrapping our lambda in a std::ref, whenever anybody tries to make a copy of our lambda, they’ll make a copy of the reference instead, which will copy the reference rather than the actual object.

Here’s our updated code using std::ref:

Our output is now as expected:


Note that the output doesn’t change even if invoke takes fn by value. std::function doesn’t create a copy of the lambda if we create it with std::ref.


Standard library functions may copy function objects (reminder: lambdas are function objects). If you want to provide lambdas with mutable captured variables, pass them by reference using std::ref.

Best practice

Try to avoid lambdas with states altogether. Stateless lambdas are easier to understand and don’t suffer from the above issues, as well as more dangerous issues that arise when you add parallel execution.

Quiz time

Question #1

Which of the following variables can be used by the lambda in main without explicitly capturing them?

Show Solution

Question #2

What does the following code print? Don’t run the code, work it out in your head.

Show Solution

Question #3

This quiz requires C++17 or newer.

We’re going to write a little game with square numbers (numbers which can be created by multiplying an integer with itself (1, 2, 4, 9, 16, 25, …)).

Ask the user to input 2 numbers, the first is the square root of the number to start at, the second in the amount to numbers to generate. Generate a random integer from 2 to 4, and square numbers in the range that was chosen by the user. Multiply each square number by the random number. You can assume that the user enters valid numbers.

The user has to calculate which numbers have been generated. The program checks if the user guessed correctly and removes the guessed number from the list. If the user guessed wrong, the game is over and the program prints the number that was closest to the user’s final guess, but only if the final guess was not off by more than 4.

Here are a couple of sample sessions to give you a better understanding of how the game works:

Start where? 4
How many? 8
I generated 8 square numbers. Do you know what each number is after multiplying it by 2?
> 32
Nice! 7 number(s) left.
> 72
Nice! 6 number(s) left.
> 50
Nice! 5 number(s) left.
> 126
126 is wrong! Try 128 next time.
  • The user chose to start at 4 and wants to play with 8 numbers.
  • Each square number will be multiplied by 2. 2 was randomly chosen by the program.
  • The program generates 8 square number, starting with 4 as a base:
  • 16 25 36 49 64 81 100 121
  • But each number is multiplied by 2, so we get:
  • 32 50 72 98 128 162 200 242
  • Now the user starts to guess. The order in which in guesses are entered doesn’t matter.
  • 32 is in the list.
  • 72 is in the list.
  • 126 is not in the list, the user loses. There is a number in the list (128) that is not more then 4 away from the user’s guess, so that number is printed.
Start where? 1
How many? 3
I generated 3 square numbers. Do you know what each number is after multiplying it by 4?
> 4
Nice! 2 numbers left.
> 16
Nice! 1 numbers left.
> 36
Nice! You found all numbers, good job!
  • The user chose to start at 1 and wants to play with 3 numbers.
  • Each square number will be multiplied by 4.
  • The program generates these square numbers:
  • 1 4 9
  • Multiplied by 4
  • 4 16 36
  • The user guesses all numbers correctly and wins the game.
Start where? 2
How many? 2
I generated 2 square numbers. Do you know what each number is after multiplying it by 4?
> 21
21 is wrong!
  • The user chose to start at 2 and wants to play with 2 numbers.
  • Each square number will be multiplied by 4.
  • The program generates these numbers:
  • 16 36
  • The user guesses 21 and loses. 21 is not close enough to any of the remaining numbers, so no number is printed.

Use std::find (7.8 -- Function Pointers) to search for a number in the list.
Use std::vector::erase to remove an element, e.g.

Use std::min_element and a lambda to find the number closest to the user’s guess. std::min_element works analogous to std::max_element from the previous quiz.

Show Hint

Show Solution

7.x -- Chapter 7 comprehensive quiz
7.15 -- Introduction to lambdas (anonymous functions)

9 comments to 7.16 — Lambda captures

  • Suyash

    Okay, I still need to attempt the exercises but I have a question... Okay, the concept of lambda captures seem like a new one... But, it seems overly complicated approach to achieve a simple task of getting access to the variables present in the enclosing scope...

    For example, let's again look at lambda capture used in the "search nut" example...

    I am just curious about the reason being the concept of lambda captures... For a person coming from another language where the same concept is implemented in a... more sophisticated fashion, this just feels a bit unintuitive...

    Why the above code is preferred over something more simple like the following? Is it due to lambdas being functors (function objects)? I know that my following code snippet doesn't work but that raises another question in my head...

    Is it not possible for us to call/invoke lambda functions like regular functions? And, should lambdas be only used as (a function) parameter to another function?

    Probably, it's due to the fact that functions can't be nested and since functors already use the overloaded () operator to declare parameters & thus, they can't be used to make calls to them...

    I know I sound like a mess but I am just confused with the idea of lambda captures... I will patiently wait for your answer...

    • nascardriver

      Your concerns are valid and your suggested code isn't unpopular either.

      > it seems overly complicated approach to achieve a simple task of getting access to the variables
      C++ is a language that's close to the system. You can do a lot, and you have a lot of control over what's happening on a low-level. But to achieve that level of control, things have to be complicated at times. Lambdas are objects, blindly copying variables into them to make them accessible would be counter-intuitive, so we get to choose between what we want to capture and how to capture it. This comes at the cost of a more verbose syntax than other languages have.

      > Why the above code is preferred over something more simple like the following?
      If you want your lambda to take another parameter, then that parameter has to get its value from somewhere. `std::find_if` passes a single container element to the function, because that's all the function should need. If the function needs more, `std::find_if` can't know that, and you have to get the value from somewhere else, enter captures.
      If you called the lambda yourself, you could add another parameter rather than capturing a variable.

      > Is it not possible for us to call/invoke lambda functions like regular functions?
      Regular functions and lambdas are used exactly the same from a syntax point of view. Internally, they're different, but that doesn't usually matter.

      > should lambdas be only used as (a function) parameter to another function?
      You can use them wherever you want (Almost). Most of the time, you'll need them as an argument for a callback or similar.

      I'm not sure I understand what you're saying. Lambdas can be called directly, that's done for complex initializations for example.

      • Suyash

        Thanks for the quick response, @nascardriver... Your answer cleared a lot of doubts regarding the concept of Lambdas & its implementation in the language...

        C++ could be considered as my third language (at the current moment after Python/JavaScript) and since I have to constantly switch between them means that I end up mixing a lot of stuff (especially in the case of C++)...

        While I love the fact that C++ has been able to introduce modern programming concepts in their core language, the verbose syntax is something that I have come to dislike (due to spending so much time in Python) but at the same time, I guess, I am also learning it to appreciate it on how much easier, it has become for me to write self-documenting code and how I can use it to describe my intent...

        Every language has its pros & cons... But, even though I have only spent a short time in C++, I do like how it has helped me become a more aware programmer... While I don't always like the motto of "Trust the programmer!" especially because I have so easily been burnt by it (on my previous attempts using C++), but now I am glad for it...

        By the way, how can I quote a post (or if possible, a particular paragraph) written by someone?

        • nascardriver

          Apart from code tags, there's nothing special about comments (Authors can use html, that's why we can use links). If I want to quote something, I copy it and add > in front.

  • Fan

    In the last example, is it possible to avoid copying of count by changing the type of the argument of invoke to auto&?

    Also, in the section "Dangling captured variables", there is an extra period after the phrase "dangling reference".

    • nascardriver

      Yes, that would work. Keep in mind that regular functions can't have `auto` parameters (Until C++20).
      Though, then the user of `invoke` doesn't know what kind of argument they can pass to `invoke`. Furthermore, that solution only works if we can modify `invoke`. If it's a function in a library, we can't modify its parameters.

      > there is an extra period
      Fixed, thanks!

  • Wilibert

    Hi, I have a question regarding the use of std::min_element... I was getting an error when I was trying this for quiz 3:

    Neither making found an int nor an int pointer worked. After looking at the solution, I noticed you were using a dereference operator right before std::min_element like so:

    And now I'm confused. Why would that work? Is it because the * operator for std::min_element calls a specially overloaded function that turns whatever type std::min_element normally returns into an int? Otherwise I can't see why an ordinary int pointer wouldn't work. I also tried changing found's type to auto and dereferencing it whenever I needed it later and it also worked. So... normal int pointer cannot contain std::min_element's return type but you can dereference that type anywhere and the compiler will do the right thing?
    Oh and thanks a lot for the lesson, I still remember when my friends were complaining after learning about lambdas (they have a proper college computer science education and I don't) so it means a lot to me to be able to learn this.

    • nascardriver

      `std::min_element` returns an iterator. If you missed the lesson on iterators (added 17. dec 2019), it's here.
      Interacting with iterators is very similar to interacting with pointers, hence `operator*` works. But that `operator*` isn't a pointer indirection, it calls a special function of the iterator, which returns the element it's currently at.
      When you use `*std::min_element(/**/)`, you're getting the element right away (If it exists, an error otherwise). When you use `auto`, you're storing the iterator for later and can use `operator*` on the iterator. There is no conversion from the iterator to a pointer.

      • Wilibert

        Okay, that makes sense. It seems like I was confusing iterators as some form of pointer since they work similarly. I'll review the lesson on iterators to make sure I understand. Thanks for the help!

Leave a Comment
