产量/迭代器极端情况

Question

在这篇文章 (http://blogs.msdn.com/oldnewthing/archive/2008/08/13/8854601.aspx) 上，有一个关于迭代器的流行问题和一个关于极端情况的问题：

练习：考虑以下内容 片段：foreach（int i in CountTo100Twice()) { ... }

解释第 150 次通话会发生什么 到上述循环中的 MoveNext() 。 讨论它对递归的影响 枚举器（如树遍历）。

我没有运行此代码，但我假设这是一个问题，据说有文章的答案（下面提供的所有链接），但我无法在文章共享的知识中找到答案或在这篇特定文章的 cmets 中。

有谁知道答案是什么？还有哪些其他极端案例？

1)http://blogs.msdn.com/oldnewthing/archive/2008/08/12/8849519.aspx

2)http://blogs.msdn.com/oldnewthing/archive/2008/08/13/8854601.aspx

3)http://blogs.msdn.com/oldnewthing/archive/2008/08/14/8862242.aspx

4)http://blogs.msdn.com/oldnewthing/archive/2008/08/15/8868267.aspx

谢谢

Answer 1

一些事情。

(1) 乔恩当然是正确的；问题是这样的嵌套迭代器为您提供了迭代器逻辑的调用堆栈。如果您正在迭代一个深度递归定义的数据结构，这可能会破坏堆栈，并且有一些简单的方法可以将应该是线性算法的东西变成二次算法。有关详细信息，请参阅 Wes 的文章。

(2) 我们可以在没有性能问题的语言中构建一种新的迭代器逻辑。我很想实现这一点，但现在它不是一个足够高的优先级。如果您对如何操作的技术细节感兴趣，请阅读this paper。

(3) 有很多极端情况；已经提到的（延迟执行边界检查和延迟执行 finally 块）是最常见的两个。不幸的是，在许多版本的 C# 中，代码生成器中存在会加剧后一个问题的错误。假设你有 try { try { ... yield ... } finally { X() } } finally { Y() } - 有一些奇怪的情况你可能会遇到我们生成的代码在 X 之前意外调用 Y() () 在清理路径上，这显然是错误的。我们已经为服务包修复了这些问题，但如果您发现其他问题，请告诉我。

(4) 还有一些现存的极其晦涩的错误涉及迭代器在执行疯狂的事情时的确切行为，例如从 finally 中退出，然后分支到外部 finally，后者执行第二个冗余的 yield 中断。同样，如果您碰巧发现行为怪异的迭代器，请随时提醒我。

Answer 2

我怀疑他可能指的是每次调用MoveNext() 都会调用一个状态机，而该状态机又会调用另一个状态机上的MoveNext()，这使得它的效率有点低。

这是关于 here by Wes Dyer 和 here by Eric Lippert 的博客。

我要说的迭代器块的主要极端情况是 nothing 在第一次调用 MoveNext() 之前执行。所以这个方法：

public IEnumerable<string> ReadLines(string file)
{
    if (file == null)
    {
        throw new ArgumentNullException("file");
    }
    using (TextReader reader = File.OpenText(file))
    {
        string line;
        while ((line = reader.ReadLine()) != null)
        {
            yield return line;
        }
    }        
}

在您开始迭代之前实际上不会抛出异常。相反，您需要编写如下内容：

public static IEnumerable<string> ReadLines(string file)
{
    if (file == null)
    {
        throw new ArgumentNullException("file");
    }
    return ReadLinesImpl(file);
}

public static IEnumerable<string> ReadLinesImpl(string file)
{
    using (TextReader reader = File.OpenText(file))
    {
        string line;
        while ((line = reader.ReadLine()) != null)
        {
            yield return line;
        }
    }        
}

同样，Eric 曾就此发表过博文：part 1、part 2。我也写了一个 suggestion to make life easier 的博客，虽然我怀疑它会不会有任何结果。

Answer 3

当您考虑try..finally 以及派生的using 和lock 语句时，会出现一个有趣的关于yield/iterators 的极端情况。考虑上面发布的迭代器块 Jon Skeet：

public IEnumerable<string> ReadLines(string file)
{
    if (file == null)
    {
        throw new ArgumentNullException("file");
    }
    using (TextReader reader = File.OpenText(file))
    {
        string line;
        while ((line = reader.ReadLine()) != null)
        {
            yield return line;
        }
    }        
}

如果您通过手动调用 MoveNext() 几次来在 foreach 的上下文之外使用此迭代器块，并且您从未完成迭代，那么 using 会发生什么情况？答：using 的finally 部分永远不会被调用，因此永远不会在TextReader 上调用Dispose 并且永远不会关闭打开的文件。同样，假设using 被替换为lock(something)。 lock 的 finally 部分永远不会被调用，永远不会释放对象上的锁。

教训：始终避免在迭代器块中使用try..finally 及其派生词。