c# - 产量/迭代器极端情况

Question

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

Exercise: Consider the following fragment: foreach (int i in CountTo100Twice()) { ... }

Explain what happens on the 150th call to MoveNext() in the above loop. Discuss its consequences for recursive enumerators (such as tree traversal).

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

有人知道答案是什么吗？还有哪些极端情况？

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) corner case比较多；已经提到的(边界检查的延迟执行和 finally block 的延迟执行)是最常见的两种。不幸的是，在许多版本的 C# 中，代码生成器中的错误加剧了后一个问题。假设您有 try { try { ... yield ... } finally { X() } } finally { Y() } —— 在某些奇怪的情况下，您可能会遇到我们生成的代码在 X 之前意外调用 Y() 的情况() 在清理路径上，这显然是错误的。我们已经为服务包修复了这些问题，但如果您找到其他问题，请告诉我。

(4) 还有一些现存的极其隐蔽的错误涉及迭代器在做一些疯狂的事情时的确切行为，例如 finally 的 yield break 然后分支到外部 finally 进行第二个冗余的 yield break。同样，如果您碰巧发现行为异常的迭代器，请随时提请我注意。