Эффективный и современный С++. 42 рекомендации по использованию С++11 и С++14 - [95]

std::find_if(container.begin(), container.end(),
             [](int val) { return 0 < val && val < 10; });

• Замыкание (closure) представляет собой объект времени выполнения, создаваемый лямбда-выражением. В зависимости от режима захвата замыкания хранят копии ссылок на захваченные данные. В приведенном выше вызове std::find_if замыкание представляет собой объект, передаваемый во время выполнения в std::find_if в качестве третьего аргумента.

• Класс замыкания (closure class) представляет собой класс, из которого инстанцируется замыкание. Каждое лямбда-выражение заставляет компиляторы генерировать уникальный класс замыкания. Инструкции внутри лямбда-выражения становятся выполнимыми инструкциями функций-членов их класса замыкания.

Лямбда-выражения часто используются для создания замыкания, которое применяется только в качестве аргумента функции. Именно этот случай представлен в приведенном выше примере std::find_if. Однако в общем случае замыкания могут копироваться, так что обычно можно иметь несколько замыканий типа замыкания, соответствующего одному лямбда-выражению. Например, в коде

{
 int x;                  // x - локальная переменная
 …
 auto c1 =               // c1 - копия замыкания,
  [x](int y) {           // сгенерированного
   return x * y > 55; }; // лямбда-выражением
 auto c2 = c1;           // c2 - копия c1
 auto c3 = c2;           // c3 - копия c2
}

c1, c2 и c3 являются копиями замыкания, порожденного лямбда-выражением.

Неформально вполне приемлемо размытие границы между лямбда-выражениями, замыканиями и классами замыканий. Но в последующих разделах очень часто важно различать, что существует во время компиляции (лямбда-выражения и классы замыканий), что — во время выполнения (замыкания) и как они соотносятся одно с другим.

6.1. Избегайте режимов захвата по умолчанию

В С++11 имеются два режима захвата: по ссылке и по значению. Захват по умолчанию по ссылке может привести к висячим ссылкам. Захват по умолчанию по значению соблазняет считать, что вы не подвержены этой проблеме (это не так), и думать, что ваши замыкания являются самодостаточными автономными замыканиями (но они могут и не быть таковыми).

Так выглядят основные положения данного раздела. Если вы в большей степени творец, чем ремесленник, вы, вероятно, захотите узнать побольше — так давайте начнем с опасности захвата по ссылке.

Захват по ссылке приводит к тому, что замыкание содержит ссылку на локальную переменную или на параметр, доступный в области видимости, где определено лямбда- выражение. Если время жизни замыкания, созданного из лямбда-выражения, превышает время жизни локальной переменной или параметра, ссылка в замыкании оказывается висячей. Предположим, например, что у нас есть контейнер с функциями фильтрации, каждая из которых принимает int и возвращает bool, указывающий, удовлетворяет ли переданное значение фильтру:

// См. using в разделе 3.3, std::function - в 2.1:
using FilterContainer = std::vector>;

FilterContainer filters; // Функции фильтрации

Мы можем добавить фильтр для чисел, кратных 5, следующим образом:

filters.emplace_back( // См. emplace_back в разделе 8.2
 [](int value) { return value % 5 == 0; }
};

Однако может быть так, что нам нужно вычислять делитель во время выполнения, т.e. мы не можем жестко “прошить” значение 5 в лямбда-выражении. Поэтому добавление фильтра может выглядеть следующим образом:

void addDivisorFilter() {
 auto calc1 = computeSomeValue1();
 auto calc2 = computeSomeValue2();
 auto divisor = computeDivisor(calc1, calc2);
 filters.emplace_back( // Опасно! Ссылка на divisor повиснет!
  [&](int value) { return value % divisor == 0; }
 );
}

Этот код — бомба замедленного действия. Лямбда-выражение ссылается на локальную переменную divisor, но эта переменная прекращает свое существование после выхода из addDivisorFilter. Этот выход осуществляется сразу после выхода из filters.emplace_back, так что добавленная в filters функция, по сути, является мертворожденной. Применение этого фильтра ведет к неопределенному моменту практически с момента создания.

Та же проблема имеет место и при явном захвате divisor по ссылке,

filters.emplace_back(
 [&divisor] (int value)           // Опасно! Ссылка на
 { return value % divisor == 0; } // divisor все равно
};                                // повисает!

но при явном захвате проще увидеть, что жизнеспособность лямбда-выражения зависит от времени жизни divisor. Кроме того, использование имени divisor напоминает нам о необходимости убедиться, что divisor существует как минимум столько же времени, сколько и замыкание лямбда-выражения. Это более конкретное напоминание, чем обобщенное “убедитесь, что ничего не висит”, о чем гласит конструкция [&].

Если вы знаете, что замыкание будет использовано немедленно (например, будучи переданным в алгоритм STL) и не будет копироваться, нет никакого риска, что ссылки, которые оно хранит, переживут локальные переменные и параметры в среде, где создано это лямбда-выражение. Вы могли бы утверждать, что в этом случае нет риска получить висячие ссылки, а следовательно, нет причин избегать режима захвата по ссылке по умолчанию. Например, наше фильтрующее лямбда-выражение может использоваться только как аргумент в алгоритме С++11