Доступ к модифицированному закрытию

В этом случае все в порядке, поскольку вы фактически выполняете делегат в пределах цикла.

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

Короче говоря, об этом следует помнить как о ловушке потенциал, но в данном случае это не повредит вам.

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

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

private sealed class Closure
{
    public string[] files;
    public int i;

    public bool YourAnonymousMethod(string name)
    {
        return name.Equals(this.files[this.i]);
    }
}

Как упоминалось выше, ваша функция работает, потому что предикаты вызываются сразу после создания. Компилятор сгенерирует что-то вроде:

private string Works()
{
    var closure = new Closure();

    closure.files = new string[3];
    closure.files[0] = "notfoo";
    closure.files[1] = "bar";
    closure.files[2] = "notbaz";

    var arrayToSearch = new string[] { "foo", "bar", "baz" };

    //this works, because the predicates are being executed during the loop
    for (closure.i = 0; closure.i < closure.files.Length; closure.i++)
    {
        if (Array.Exists(arrayToSearch, closure.YourAnonymousMethod))
            return closure.files[closure.i];
    }

    return null;
}

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

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

Captured outer variables When an outer variable is referenced by an anonymous function, the outer variable is said to have been captured by the anonymous function. Ordinarily, the lifetime of a local variable is limited to execution of the block or statement with which it is associated (Local variables). However, the lifetime of a captured outer variable is extended at least until the delegate or expression tree created from the anonymous function becomes eligible for garbage collection.

Внешние переменные в MSDN

When a local variable or a value parameter is captured by an anonymous function, the local variable or parameter is no longer considered to be a fixed variable (Fixed and moveable variables), but is instead considered to be a moveable variable. Thus any unsafe code that takes the address of a captured outer variable must first use the fixed statement to fix the variable. Note that unlike an uncaptured variable, a captured local variable can be simultaneously exposed to multiple threads of execution.