Привет, Хабр!
Лямбды в C++ существуют с 2011 года, и за пятнадцать лет вокруг них накопилось столько неочевидностей, что они до сих пор регулярно встречаются на код-ревью даже у senior-разработчиков. Захваты по ссылке, время жизни this, mutable-семантика, поведение в range-based for, ограничения std::function: каждая из этих тем выглядит элементарной в отрыве, но в боевом коде одна неосторожная лямбда превращается в undefined behavior, который не ловится компилятором и проявляется в продакшене через крэш или, что хуже, через тихое повреждение данных.
Дальше пять задач, в которых легко споткнуться. Попробуйте решить их в уме до того, как откроете разбор. Если три из пяти решите правильно, понимание лямбд у вас выше среднего.
Задача 1: захват по ссылке локальной переменной
Функция возвращает лямбду, которая ссылается на локальное состояние:
#include <functional>
#include <iostream>
std::function<int()> make_counter() {
int count = 0;
return [&count]() {
return ++count;
};
}
int main() {
auto counter = make_counter();
std::cout << counter() << '\n';
std::cout << counter() << '\n';
std::cout << counter() << '\n';
}Программа компилируется без ошибок, без предупреждений в большинстве компиляторов, иногда даже выдаёт ожидаемые 1, 2, 3 в debug-сборке. Что в реальности происходит и почему вывод нельзя считать корректным?
Лямбда захватывает count по ссылке через [&count]. Локальная переменная count живёт в стек-фрейме функции make_counter до момента возврата из неё. После возврата стек-фрейм перестаёт существовать, и память, где лежал count, либо переиспользуется следующими вызовами, либо остаётся со старым значением до тех пор, пока никто не записал туда что-то новое. Лямбда внутри std::function теперь содержит висячую ссылку, обращение к ней при каждом вызове - counter() это undefined behavior.
В debug-сборке часто получается «корректный» вывод по простой причине: после возврата из make_counter стек-фрейм не затирается сразу, область памяти остаётся нетронутой до следующего вызова. В release-сборке с оптимизациями компилятор может переиспользовать ту же память для других переменных в main, и значения начнут вести себя случайным образом. Под санитайзером AddressSanitizer этот код падает с ошибкой stack-use-after-return и показывает точное место проблемы.
Решение: захватывать по значению, что копирует переменную в storage самой лямбды:
std::function<int()> make_counter() {
int count = 0;
return [count]() mutable {
return ++count;
};
}Здесь count копируется в саму лямбду, mutable нужен, потому что по умолчанию лямбда с захватом по значению создаёт operator() с квалификатором const, и менять захваченные значения нельзя. С mutable всё работает: счётчик хранится внутри лямбды, переживает любые перемещения и копирования объекта std::function.
GCC 13+ и Clang 16+ с флагом -Wdangling-reference (включён в -Wall начиная с GCC 14) выдают предупреждение в подобных случаях, но реально срабатывает оно не везде. Поэтому правило простое: захватывать по ссылке, только если точно знаете, что лямбда не переживёт область видимости захваченных переменных.
Задача 2: захват this с переживанием объекта
Класс регистрирует callback на сервис уведомлений и забывает о нём:
#include <functional>
#include <string>
#include <vector>
#include <iostream>
class NotificationService {
public:
void subscribe(std::function<void(const std::string&)> handler) {
handlers_.push_back(std::move(handler));
}
void notify(const std::string& message) {
for (const auto& h : handlers_) h(message);
}
private:
std::vector<std::function<void(const std::string&)>> handlers_;
};
class UserSession {
public:
UserSession(NotificationService& service, std::string username)
: username_(std::move(username)) {
service.subscribe([this](const std::string& msg) {
std::cout << username_ << " received: " << msg << '\n';
});
}
private:
std::string username_;
};
int main() {
NotificationService service;
{
UserSession alice(service, "alice");
service.notify("hello");
}
service.notify("world");
}Первый вызов notify работает корректно и выводит «alice received: hello». Второй вызов notify после уничтожения alice приводит к undefined behavior. Какое исправление архитектурно правильное и почему банальный захват username_ по значению вместо this решает не всю проблему?
Лямбда захватывает this, что фактически означает захват указателя на объект UserSession. Когда alice уничтожается в конце блока, указатель остаётся в NotificationService::handlers_, и при следующем notify через этот указатель идёт обращение к уничтоженному объекту.
Захват username_ по значению (через [username = username_] или просто [*this] начиная с C++17) убирает обращение к мёртвому объекту, но решает только верхний слой проблемы. Главная архитектурная проблема не в этом: callback продолжает жить и вызываться, хотя сущность, к которой он относился, уже мертва. В большинстве систем это не то поведение, которое хотел разработчик. Если alice вышла из сессии, она не должна получать уведомления.
Правильное решение использует механизм деподписки. Самый распространённый вариант в современном C++: weak_ptr вместе с shared_ptr плюс проверка валидности в начале callback.
class UserSession : public std::enable_shared_from_this<UserSession> {
public:
static std::shared_ptr<UserSession> create(NotificationService& service, std::string username) {
auto session = std::shared_ptr<UserSession>(new UserSession(std::move(username)));
std::weak_ptr<UserSession> weak = session;
service.subscribe([weak](const std::string& msg) {
if (auto self = weak.lock()) {
std::cout << self->username_ << " received: " << msg << '\n';
}
});
return session;
}
private:
explicit UserSession(std::string username) : username_(std::move(username)) {}
std::string username_;
};Теперь callback держит weak_ptr, который не продлевает время жизни объекта. При вызове weak.lock() возвращается либо shared_ptr на живой объект (и callback выполняется), либо пустой shared_ptr (и callback тихо пропускается). Эта схема стандартная для асинхронных систем на C++ и встречается в Boost.Asio, Folly, Qt и многих других местах.
Альтернативный подход без shared_ptr: возвращать из subscribe какой-то id и иметь явный метод unsubscribe, который вызывается в деструкторе подписчика.
Задача 3: mutable lambda копирует, а не разделяет состояние
Сценарий с распределением работы между несколькими worker-потоками. Каждый поток получает свою копию лямбды, но логически счётчик должен быть один:
#include <iostream>
#include <thread>
#include <vector>
void run_workers() {
int processed = 0;
auto worker = [processed]() mutable {
for (int i = 0; i < 100; ++i) {
++processed;
}
std::cout << "Worker processed: " << processed << '\n';
};
std::vector<std::thread> threads;
for (int i = 0; i < 5; ++i) {
threads.emplace_back(worker);
}
for (auto& t : threads) t.join();
std::cout << "Total processed: " << processed << '\n';
}Каждый из пяти worker-потоков выводит «Worker processed: 100», в финале «Total processed: 0». Разработчик ожидал увидеть 500 в финале (пять воркеров обработали по 100 элементов). Что пошло не так и какие два решения тут есть, в зависимости от того, что вообще требовалось?
mutable lambda хранит захваченные переменные внутри объекта самой лямбды. Когда лямбда передаётся в std::thread или копируется в threads.emplace_back(worker), копируется и её внутреннее состояние. Каждый поток получает свою независимую копию processed, увеличивает её до 100 и завершается. Переменная processed в run_workers - это совсем другая переменная, которая не менялась ни разу, потому что захват был по значению.
Решение зависит от того, что хотел программист.
Если задача состояла в том, чтобы каждый воркер посчитал свою порцию работы независимо, никакой проблемы и нет, всё работает корректно. В финале нужно либо собрать результаты от воркеров через future, либо использовать atomic-счётчик:
#include <atomic>
void run_workers() {
std::atomic<int> processed{0};
auto worker = [&processed]() {
for (int i = 0; i < 100; ++i) {
processed.fetch_add(1, std::memory_order_relaxed);
}
};
std::vector<std::thread> threads;
for (int i = 0; i < 5; ++i) {
threads.emplace_back(worker);
}
for (auto& t : threads) t.join();
std::cout << "Total processed: " << processed.load() << '\n';
}Захват processed по ссылке плюс atomic-операции дают разделяемый между потоками счётчик, который инкрементируется без data race и виден после join всех потоков. Memory ordering relaxed достаточен, потому что нет зависимости от других переменных.
Если задача состояла в том, чтобы каждый воркер вёл свой локальный счётчик и не было shared state, то и без atomic всё работало бы, только финальное значение надо получать через future:
#include <future>
void run_workers() {
std::vector<std::future<int>> futures;
for (int i = 0; i < 5; ++i) {
futures.push_back(std::async(std::launch::async, []() {
int processed = 0;
for (int j = 0; j < 100; ++j) ++processed;
return processed;
}));
}
int total = 0;
for (auto& f : futures) total += f.get();
std::cout << "Total processed: " << total << '\n';
}mutable lambda в реальном коде нужна сравнительно редко: либо для memo-функций со внутренним состоянием, либо для функторов, которые передаются один раз и не копируются. В большинстве случаев, когда хочется поставить mutable, на самом деле нужен либо захват по ссылке плюс atomic, либо архитектура без разделяемого состояния.
Задача 4: захват переменной из range-based for
Код собирает callbacks, каждый из которых должен запомнить значение из контейнера на момент создания:
#include <functional>
#include <iostream>
#include <vector>
std::vector<std::function<void()>> create_callbacks() {
std::vector<int> data = {1, 2, 3, 4, 5};
std::vector<std::function<void()>> callbacks;
for (const auto& value : data) {
callbacks.push_back([&value]() {
std::cout << value << ' ';
});
}
return callbacks;
}
int main() {
auto callbacks = create_callbacks();
for (const auto& cb : callbacks) cb();
std::cout << '\n';
}Программа выводит «5 5 5 5 5» (или другую последовательность одинаковых чисел, или вообще мусор) вместо ожидаемого «1 2 3 4 5». В чём подвох именно с range-based for, чего бы не случилось с обычным for-циклом по индексу?
value - это ссылочная переменная в range-based for. В каждой итерации она привязывается к следующему элементу контейнера, но это одна и та же ссылочная переменная, которая просто переуказывает. Лямбда захватывает её по ссылке через [&value], и все лямбды получают ссылку на одну и ту же переменную value.
После выхода из цикла переменная value уничтожается, и каждая лямбда содержит висячую ссылку. Дальше плюс тот факт, что create_callbacks возвращает callbacks, выходя из функции, ссылка указывает на стек-фрейм, который уже не существует. Двойное undefined behavior.
Решение очевидное, но не сразу заметное при беглом чтении: захватывать значение, а не ссылку.
for (const auto& value : data) {
callbacks.push_back([value]() {
std::cout << value << ' ';
});
}Теперь каждая лямбда копирует текущее значение value в свой собственный storage, и все пять лямбд получают разные числа. Программа выводит «1 2 3 4 5».
Особенность range-based for в том, что промежуточная переменная цикла одна на весь цикл, в отличие от языков вроде JavaScript с let-биндингом, где для каждой итерации создаётся новая переменная. В C++ это сделано из соображений производительности, но цена для лямбд высока: захват по ссылке в цикле почти всегда ошибка, кроме случаев, когда лямбда гарантированно выполняется до конца итерации.
Если очень нужен захват по ссылке (например, дорогой объект, который нельзя копировать), стоит использовать структуру shared_ptr и захватывать его по значению, или использовать capture init с C++14:
for (const auto& value : data) {
callbacks.push_back([v = value]() {
std::cout << v << ' ';
});
}Capture init копирует выражение в новую переменную внутри лямбды, что эквивалентно [value] для простых типов.
Задача 5: move-only типы в std::function
Современный код часто работает с unique_ptr, который запрещает копирование. Логично попытаться захватить такой объект в лямбде:
#include <functional>
#include <memory>
#include <iostream>
struct Resource {
Resource() { std::cout << "Resource constructed\n"; }
~Resource() { std::cout << "Resource destroyed\n"; }
void use() { std::cout << "Resource used\n"; }
};
int main() {
auto resource = std::make_unique<Resource>();
std::function<void()> task = [r = std::move(resource)]() {
r->use();
};
task();
}Компилятор отказывается компилировать этот код с длинным сообщением про то, что unique_ptr не копируется. Сама лямбда [r = std::move(resource)] не копируется вместе с unique_ptr, проблема возникает на этапе обёртки в std::function.
Почему std::function это не выдерживает и какой стандартный способ обойти ограничение в C++23?
std::function требует, чтобы хранящийся в нём callable был копируемым. Это требование заложено в стандарте C++11 и не убрано до сих пор: внутри std::function может потребоваться копировать обёртку, например, при копировании самой std::function. Лямбда [r = std::move(resource)] копируема только если все её захваченные типы копируемы, а unique_ptr копируемым не является.
Логика стандартного std::function устарела за прошедшие пятнадцать лет. В современном C++ move-only callbacks встречаются сплошь и рядом: capture unique_ptr, capture файлового дескриптора, capture coroutine handle.
В C++23 в стандарте появился std::move_only_function ровно для этого случая. Он работает почти как std::function, но не требует копируемости хранящегося callable:
#include <functional>
#include <memory>
int main() {
auto resource = std::make_unique<Resource>();
std::move_only_function<void()> task = [r = std::move(resource)]() {
r->use();
};
task();
}Этот код компилируется и работает, потому что std::move_only_function хранит callable и не требует возможности его копирования. Сам объект task move-only: его можно перемещать, но не копировать. В большинстве сценариев move-семантика как раз и нужна (передача между потоками, хранение в контейнере).
Если по каким-то причинам C++23 ещё недоступен (старая платформа, корпоративные ограничения на стандарт), стандартный обходной путь это shared_ptr вместо unique_ptr:
auto resource = std::make_shared<Resource>();
std::function<void()> task = [resource]() {
resource->use();
};Shared_ptr копируется без проблем, лямбда копируется, std::function счастлива. Платится за это атомарным счётчиком ссылок, что для большинства callback-сценариев несущественно. Но архитектурно правильнее перейти на std::move_only_function, если стандарт позволяет.
В C++26 (ожидается осенью 2026) появилось дополнение std::copyable_function, которое явно обозначает требование копируемости, и старый std::function постепенно переводится в категорию устаревших с точки зрения именования. Сейчас рекомендация такова: новый код пишем на std::move_only_function или std::copyable_function в зависимости от требований, std::function оставляем для legacy-совместимости.
Что забрать в работу
Все пять задач выше показывают одно и то же: внешняя простота лямбд скрывает много неявного поведения вокруг времени жизни захваченных объектов и взаимодействия с обёртками. Захват по ссылке локальной переменной даёт dangling reference при возврате из функции. Захват this не учитывает время жизни объекта. Mutable lambda копирует состояние, а не разделяет его между копиями. Захват в range-based for ссылается на одну и ту же переменную цикла. Move-only типы не пролезают через классический std::function.
Все ситуации компилируются без ошибок и часто без предупреждений. Часть ловится санитайзерами в runtime, часть только бенчмарками или анализаторами кода. Практическое правило: захватывать по значению по умолчанию, переходить на захват по ссылке только если уверены, что лямбда не переживёт область видимости захваченных переменных. Для долгоживущих лямбд (в std::function, callbacks, std::thread) использовать смарт-указатели для управления временем жизни и явный механизм отмены подписок.
Современные стандарты постепенно закрывают исторические углы: с C++17 появился захват [*this], копирующий объект целиком, с C++23 пришёл std::move_only_function для callable с unique_ptr, в C++26 фиксируется явное разделение copyable и move-only функций. Если стандарт проекта позволяет, эти средства убирают значительную часть проблем.
Хотите глубже разобраться в современном C++ не только по статьям, но и на живых примерах из практики? Приходите на открытые уроки OTUS — их ведут преподаватели-практики, которые каждый день работают с промышленной разработкой и разбирают не абстрактную теорию, а реальные инженерные ошибки.
30 июня, 20:00. «RAII в C++: фундамент надёжного управления ресурсами». Записаться
разберём, как управлять ресурсами так, чтобы код был устойчивее к утечкам, исключениям и ошибкам времени жизни.2 июля, 20:00. «Всё, что нужно знать об управлении памятью в C++». Записаться
поговорим о памяти, владении объектами и типичных ловушках, которые приводят к undefined behavior.16 июля, 20:00. «Выразительный C++: кодируем намерения». Записаться
обсудим, как писать код, в котором лучше видны ownership, ограничения и ожидания разработчика.
Больше открытых уроков по разработке, инфраструктуре, аналитике, ИИ и другим ИТ-направлениям — в дайджесте.