Я встретил интересную проблему о C #. У меня есть код, как показано ниже.

List<Func<int>> actions = new List<Func<int>>();

int variable = 0;
while (variable < 5)
{
    actions.Add(() => variable * 2);
    ++ variable;
}

foreach (var act in actions)
{
    Console.WriteLine(act.Invoke());
}

Я ожидаю, что он выведет 0, 2, 4, 6, 8. Однако на самом деле он выдает пять 10 с.

Кажется, что это происходит из-за всех действий, относящихся к одной захваченной переменной. В результате, когда их вызывают, все они имеют одинаковый вывод.

Есть ли способ обойти это ограничение, чтобы каждый экземпляр действия имел свою собственную захваченную переменную?

Да - взять копию переменной внутри цикла:

while (variable < 5)
{
    int copy = variable;
    actions.Add(() => copy * 2);
    ++ variable;
}

Вы можете думать об этом так, как будто компилятор C # создает «новую» локальную переменную каждый раз, когда попадает в объявление переменной. На самом деле он создаст соответствующие новые объекты замыкания, и он станет сложным (с точки зрения реализации), если вы обращаетесь к переменным в нескольких областях, но это работает :)

Обратите внимание, что более распространенным явлением этой проблемы является использование forили foreach:

for (int i=0; i < 10; i++) // Just one variable
foreach (string x in foo) // And again, despite how it reads out loud

См. Раздел 7.14.4.2 спецификации C # 3.0 для более подробной информации, и моя статья о замыканиях также имеет больше примеров.

Обратите внимание, что начиная с компилятора C # 5 и выше (даже при указании более ранней версии C #) поведение foreachизменилось, поэтому вам больше не нужно делать локальное копирование. Смотрите этот ответ для более подробной информации.

Я считаю, что то, что вы испытываете, называется «Закрытие» http://en.wikipedia.org/wiki/Closure_(computer_science) . Ваша лямба имеет ссылку на переменную, которая выходит за пределы самой функции. Ваша лямба не интерпретируется до тех пор, пока вы ее не вызовете, и, как только она появится, она получит значение, которое переменная имеет во время выполнения.

За кулисами компилятор генерирует класс, который представляет замыкание для вашего вызова метода. Он использует этот единственный экземпляр класса замыкания для каждой итерации цикла. Код выглядит примерно так, что упрощает понимание причины ошибки:

void Main()
{
    List<Func<int>> actions = new List<Func<int>>();

    int variable = 0;

    var closure = new CompilerGeneratedClosure();

    Func<int> anonymousMethodAction = null;

    while (closure.variable < 5)
    {
        if(anonymousMethodAction == null)
            anonymousMethodAction = new Func<int>(closure.YourAnonymousMethod);

        //we're re-adding the same function 
        actions.Add(anonymousMethodAction);

        ++closure.variable;
    }

    foreach (var act in actions)
    {
        Console.WriteLine(act.Invoke());
    }
}

class CompilerGeneratedClosure
{
    public int variable;

    public int YourAnonymousMethod()
    {
        return this.variable * 2;
    }
}

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

Способ обойти это - сохранить нужное значение в прокси-переменной и получить эту переменную.

IE

while( variable < 5 )
{
    int copy = variable;
    actions.Add( () => copy * 2 );
    ++variable;
}

Это не имеет ничего общего с петлями.

Это поведение вызвано тем, что вы используете лямбда-выражение, () => variable * 2где внешняя область variableне определена во внутренней области лямбда-выражения .

Лямбда-выражения (в C # 3 +, а также анонимные методы в C # 2) по-прежнему создают реальные методы. Передача переменных в эти методы сопряжена с некоторыми дилеммами (передача по значению, передача по ссылке, C # идет по ссылке, но это открывает еще одну проблему, когда ссылка может пережить действительную переменную). Что C # делает, чтобы разрешить все эти дилеммы, так это создать новый вспомогательный класс («замыкание») с полями, соответствующими локальным переменным, используемым в лямбда-выражениях, и методами, соответствующими фактическим лямбда-методам. Любые изменения variableв вашем коде фактически переводятся вClosureClass.variable

Таким образом, ваш цикл while продолжает обновлять ClosureClass.variableдо тех пор, пока он не достигнет 10, тогда цикл for выполняет действия, которые все работают одинаково ClosureClass.variable.

Чтобы получить ожидаемый результат, вам нужно создать разделение между переменной цикла и закрываемой переменной. Вы можете сделать это, введя другую переменную, а именно:

List<Func<int>> actions = new List<Func<int>>();
int variable = 0;
while (variable < 5)
{
    var t = variable; // now t will be closured (i.e. replaced by a field in the new class)
    actions.Add(() => t * 2);
    ++variable; // changing variable won't affect the closured variable t
}
foreach (var act in actions)
{
    Console.WriteLine(act.Invoke());
}

Вы также можете переместить замыкание на другой метод для создания этого разделения:

List<Func<int>> actions = new List<Func<int>>();

int variable = 0;
while (variable < 5)
{
    actions.Add(Mult(variable));
    ++variable;
}

foreach (var act in actions)
{
    Console.WriteLine(act.Invoke());
}

Вы можете реализовать Mult как лямбда-выражение (неявное закрытие)

static Func<int> Mult(int i)
{
    return () => i * 2;
}

или с реальным классом помощника:

public class Helper
{
    public int _i;
    public Helper(int i)
    {
        _i = i;
    }
    public int Method()
    {
        return _i * 2;
    }
}

static Func<int> Mult(int i)
{
    Helper help = new Helper(i);
    return help.Method;
}

В любом случае, «замыкания» не являются концепцией, связанной с циклами , а скорее с анонимными методами / лямбда-выражениями, использующими локальные переменные в области видимости - хотя некоторые неосторожные использования циклов демонстрируют ловушки замыканий.

Да, вам нужно создать область variableвнутри цикла и передать ее в лямбду следующим образом:

List<Func<int>> actions = new List<Func<int>>();

int variable = 0;
while (variable < 5)
{
    int variable1 = variable;
    actions.Add(() => variable1 * 2);
    ++variable;
}

foreach (var act in actions)
{
    Console.WriteLine(act.Invoke());
}

Console.ReadLine();

Та же самая ситуация происходит в многопоточности (C #, .NET 4.0].

Смотрите следующий код:

Цель - распечатать 1,2,3,4,5 по порядку.

for (int counter = 1; counter <= 5; counter++)
{
    new Thread (() => Console.Write (counter)).Start();
}

Вывод интересный! (Это может быть как 21334 ...)

Единственное решение - использовать локальные переменные.

for (int counter = 1; counter <= 5; counter++)
{
    int localVar= counter;
    new Thread (() => Console.Write (localVar)).Start();
}

Поскольку никто здесь прямо не цитирует ECMA-334 :

10.4.4.10 Для заявлений

Проверка определенного присваивания для оператора for в форме:

for (for-initializer; for-condition; for-iterator) embedded-statement

делается так, как если бы заявление было написано:

{
    for-initializer;
    while (for-condition) {
        embedded-statement;
    LLoop: for-iterator;
    }
}

Далее в спецификации,

12.16.6.3 Создание локальных переменных

Локальная переменная считается созданной, когда выполнение входит в область действия переменной.

[Пример: например, когда вызывается следующий метод, локальная переменная xсоздается и инициализируется три раза - по одному разу для каждой итерации цикла.

static void F() {
  for (int i = 0; i < 3; i++) {
    int x = i * 2 + 1;
    ...
  }
}

Однако перемещение объявления за xпределы цикла приводит к единственному созданию x:

static void F() {
  int x;
  for (int i = 0; i < 3; i++) {
    x = i * 2 + 1;
    ...
  }
}

конец примера]

Если это не зафиксировано, нет способа точно определить, как часто создается экземпляр локальной переменной - поскольку время жизни экземпляров не пересекается, для каждого экземпляра можно просто использовать одно и то же место хранения. Однако, когда анонимная функция захватывает локальную переменную, эффекты реализации становятся очевидными.

[Пример: пример

using System;

delegate void D();

class Test{
  static D[] F() {
    D[] result = new D[3];
    for (int i = 0; i < 3; i++) {
      int x = i * 2 + 1;
      result[i] = () => { Console.WriteLine(x); };
    }
  return result;
  }
  static void Main() {
    foreach (D d in F()) d();
  }
}

производит вывод:

1
3
5

Однако, когда объявление xперемещается за пределы цикла:

static D[] F() {
  D[] result = new D[3];
  int x;
  for (int i = 0; i < 3; i++) {
    x = i * 2 + 1;
    result[i] = () => { Console.WriteLine(x); };
  }
  return result;
}

выход:

5
5
5

Обратите внимание, что компилятору разрешено (но не обязательно) оптимизировать три экземпляра в один экземпляр делегата (§11.7.2).

Если цикл for объявляет переменную итерации, сама эта переменная считается объявленной вне цикла. [Пример: Таким образом, если пример изменяется для захвата самой переменной итерации:

static D[] F() {
  D[] result = new D[3];
  for (int i = 0; i < 3; i++) {
    result[i] = () => { Console.WriteLine(i); };
  }
  return result;
}

захватывается только один экземпляр итерационной переменной, который выдает:

3
3
3

конец примера]

О да, я думаю, следует упомянуть, что в C ++ эта проблема не возникает, потому что вы можете выбрать, будет ли переменная захвачена по значению или по ссылке (см .: лямбда-захват ).

Это называется проблемой закрытия, просто используйте переменную копирования, и все готово.

List<Func<int>> actions = new List<Func<int>>();

int variable = 0;
while (variable < 5)
{
    int i = variable;
    actions.Add(() => i * 2);
    ++ variable;
}

foreach (var act in actions)
{
    Console.WriteLine(act.Invoke());
}