C++, End to End

Lambdas and Function Objects

A lambda is an anonymous function you can define right where you need it, often as an argument to another function. Before lambdas existed (pre-C++11), the idiom for "a value that behaves like a function" was a function object, a class with operator() overloaded. Lambdas mostly replaced that pattern for one-off cases, but function objects are still exactly what a lambda compiles down to, so understanding both makes the whole idea click.

Lambda syntax, piece by piece

c++ · live, editable, runnableOpen in Compiler Explorer ↗

Breaking down [](int a, int b) { return a + b; }:

[] is the capture list: what variables from the surrounding scope the lambda can see. Empty here, so it can only use its own parameters.
(int a, int b) is the parameter list, exactly like a regular function.
{ return a + b; } is the body, exactly like a regular function.
The return type is deduced automatically here. You can specify it explicitly with -> int after the parameter list if the deduction would be ambiguous or you just want to be explicit.

Capturing by value vs by reference

c++ · live, editable, runnableOpen in Compiler Explorer ↗

#include <iostream> int main() { int multiplier = 3; auto byValue = [multiplier](int x) { return x * multiplier; }; auto byRef = [&multiplier](int x) { return x * multiplier; }; multiplier = 10; std::cout << byValue(5) << "\n"; // 15: captured a COPY of multiplier when it was 3 std::cout << byRef(5) << "\n"; // 50: captured a reference, sees the current value }

[=] captures everything used in the body by value; [&] captures everything used by reference. Mixing is allowed too, [x, &y] captures x by value and y by reference specifically. Prefer naming exactly what you capture over the blanket [=]/[&] forms once a lambda gets non-trivial: it documents intent, and it avoids accidentally capturing something you didn't mean to.

The dangling-reference risk

A lambda that captures by reference is only as valid as the thing it references. If the lambda outlives the variable it captured (stored for later, returned from a function, handed off to run asynchronously), that reference dangles, and using it is undefined behavior, exactly like any other dangling reference.

c++ · live, editable, runnableOpen in Compiler Explorer ↗

#include <iostream> #include <functional> std::function<int()> makeBrokenCounter() { int count = 0; // local variable return [&count]() { return ++count; }; // captures "count" BY REFERENCE // "count" is destroyed when makeBrokenCounter() returns. // The returned lambda now holds a dangling reference. } int main() { auto counter = makeBrokenCounter(); // std::cout << counter(); // undefined behavior: reads through a dangling reference }

The fix is almost always to capture by value instead when the lambda's lifetime might outlast the enclosing scope:

c++ · live, editable, runnableOpen in Compiler Explorer ↗

// godbolt-run #include <iostream> #include <functional> std::function<int()> makeCounter() { int count = 0; return [count]() mutable { return ++count; }; // captures a COPY, owned by the lambda itself } int main() { auto counter = makeCounter(); std::cout << counter() << "\n"; // 1 std::cout << counter() << "\n"; // 2 std::cout << counter() << "\n"; // 3 }

Note the mutable keyword there. A lambda's captured-by-value members are const by default (calling the lambda can't modify its own copies), so a lambda that needs to modify its captured state across calls, like this counter incrementing its own copy of count, needs mutable to allow it.

Function objects (functors)

A function object is any class with operator() overloaded, letting an instance of it be called like a function. This is exactly what lambdas desugar to: every lambda is compiler-generated syntactic sugar for an anonymous class with an operator(), and (for reference captures) member references to whatever it captured.

c++ · live, editable, runnableOpen in Compiler Explorer ↗

#include <iostream> class Multiplier { int factor; public: Multiplier(int f) : factor(f) {} int operator()(int x) const { return x * factor; } }; int main() { Multiplier triple(3); std::cout << triple(5) << "\n"; // 15, called just like a function // This is roughly what the compiler generates for a capturing lambda: auto tripleLambda = [factor = 3](int x) { return x * factor; }; std::cout << tripleLambda(5) << "\n"; // 15, same idea }

Writing a function object by hand today is rare, lambdas are shorter and clearer for almost every case a functor used to handle. It's worth knowing the pattern anyway: you'll see it in older code, and understanding that a lambda IS a function object (just one the compiler writes for you) removes a lot of the mystery around what capture actually means underneath.

std::function and its tradeoff

std::function<Signature> is a type-erased wrapper that can hold any callable matching a given signature, a lambda, a function pointer, a function object, regardless of its actual underlying type. This is genuinely useful when you need to store heterogeneous callables (a vector of different callbacks, say) or pass a callable across an API boundary without templating that API on the callable's exact type.

c++ · live, editable, runnableOpen in Compiler Explorer ↗

#include <iostream> #include <functional> #include <vector> int main() { std::vector<std::function<int(int)>> operations; int factor = 2; operations.push_back([factor](int x) { return x * factor; }); operations.push_back([](int x) { return x + 100; }); for (auto& op : operations) { std::cout << op(5) << "\n"; // 10, then 105 } }

The tradeoff: std::function erases the callable's real type behind a virtual-call-like interface, which typically means a small heap allocation for anything that doesn't fit in its internal small-buffer optimization, plus indirect call overhead. A template parameter (template <typename Callable> void apply(Callable f)) keeps the callable's real type known at compile time, so the compiler can inline the call, no allocation, no indirection, but it means the function itself must be a template, which isn't always possible or desirable (e.g. it can't appear in a stored member of a non-template class, or across a compiled library boundary). Reach for std::function when you genuinely need runtime polymorphism over callables; reach for a template parameter when you don't.

Try it yourself: fix a dangling capture›

This function returns a lambda that's supposed to check whether a number is above a threshold set at call time. It has the same dangling-reference bug shown above. Find and fix it.

c++

std::function<bool(int)> makeThresholdCheck(int threshold) {
    return [&threshold](int x) { return x > threshold; }; // BUG: captures a reference to a parameter
}

c++ · live, editable, runnableOpen in Compiler Explorer ↗

// godbolt-run #include <iostream> #include <functional> std::function<bool(int)> makeThresholdCheck(int threshold) { return [threshold](int x) { return x > threshold; }; // capture by value: owns its own copy } int main() { auto isAdult = makeThresholdCheck(18); std::cout << std::boolalpha; std::cout << isAdult(15) << "\n"; // false std::cout << isAdult(25) << "\n"; // true }

threshold is a function parameter, a local variable that stops existing the moment makeThresholdCheck returns. Capturing it by reference produces exactly the same dangling-reference bug as the counter example above, just with a parameter instead of a local variable. The fix is identical: capture by value so the lambda owns its own independent copy.