在 C# 中使用 yield return 迭代器的目的/优势是什么？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/1088442/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
What is the purpose/advantage of using yield return iterators in C#?
提问by CoderDennis
All of the examples I've seen of using yield return x;inside a C# method could be done in the same way by just returning the whole list. In those cases, is there any benefit or advantage in using the yield returnsyntax vs. returning the list?
我所看到的yield return x;在 C# 方法中使用的所有示例都可以通过返回整个列表以相同的方式完成。在这些情况下，使用yield return语法与返回列表有什么好处或优势吗？
Also, in what types of scenarios would yield returnbe used that you couldn't just return the complete list?
另外，在哪些类型的场景yield return中您不能只返回完整列表？
采纳答案by Mehrdad Afshari
But what if you were building a collection yourself?
但是如果你自己建立一个集合呢？
In general, iterators can be used to lazily generate a sequence of objects. For example Enumerable.Rangemethod does not have any kind of collection internally. It just generates the next number on demand. There are many uses to this lazy sequence generation using a state machine. Most of them are covered under functional programming concepts.
通常，迭代器可用于懒惰地生成对象序列。例如Enumerable.Range方法在内部没有任何类型的集合。它只是按需生成下一个数字。这种使用状态机的惰性序列生成有很多用途。它们中的大多数都包含在函数式编程概念中。
In my opinion, if you are looking at iterators just as a way to enumerate through a collection (it's just one of the simplest use cases), you're going the wrong way. As I said, iterators are means for returning sequences. The sequence might even be infinite. There would be no way to return a list with infinite length and use the first 100 items. It hasto be lazy sometimes. Returning a collection is considerably different from returning a collection generator(which is what an iterator is). It's comparing apples to oranges.
在我看来，如果您将迭代器视为枚举集合的一种方式（这只是最简单的用例之一），那么您就走错了路。正如我所说，迭代器是返回序列的手段。序列甚至可能是无限的。没有办法返回无限长度的列表并使用前 100 个项目。它有偷懒的时候。返回一个集合与返回一个集合生成器（这就是迭代器）有很大的不同。这是将苹果与橙子进行比较。
Hypothetical example:
假设示例：
static IEnumerable<int> GetPrimeNumbers() {
for (int num = 2; ; ++num)
if (IsPrime(num))
yield return num;
}
static void Main() {
foreach (var i in GetPrimeNumbers())
if (i < 10000)
Console.WriteLine(i);
else
break;
}
This example prints prime numbers less than 10000. You can easily change it to print numbers less than a million without touching the prime number generation algorithm at all. In this example, you can't return a list of all prime numbers because the sequence is infinite and the consumer doesn't even know how many items it wants from the start.
此示例打印小于 10000 的素数。您可以轻松地将其更改为打印小于一百万的数字，而根本不涉及素数生成算法。在这个例子中，你不能返回一个包含所有质数的列表，因为这个序列是无限的，而且消费者从一开始就不知道它想要多少个项目。
回答by Dan Davies Brackett
In toy/demonstration scenarios, there isn't a lot of difference. But there are situations where yielding iterators are useful - sometimes, the entire list isn't available (e.g. streams), or the list is computationally expensive and unlikely to be needed in its entirety.
在玩具/演示场景中，没有太大区别。但是在某些情况下，产生迭代器很有用 - 有时，整个列表不可用（例如流），或者列表的计算成本很高并且不太可能完全需要。
回答by nilamo
If the entire list is gigantic, it might eat a lot of memory just to sit around, whereas with the yield you only play with what you need, when you need it, regardless of how many items there are.
如果整个列表很大，它可能只是坐下来吃掉很多内存，而使用 yield 你只玩你需要的东西，当你需要它时，不管有多少项目。
回答by JP Alioto
Take a look at this discussion on Eric White's blog (excellent blog by the way) on lazy versus eager evaluation.
看看 Eric White 的博客（顺便说一下优秀的博客）上关于懒惰与急切评估的讨论。
回答by AgileJon
Using the yield returnyou can iterate over items without ever having to build a list. If you don't need the list, but want to iterate over some set of items it can be easier to write
使用yield return可以迭代项目而无需构建列表。如果您不需要列表，但想要迭代某些项目集，则编写起来会更容易
foreach (var foo in GetSomeFoos()) {
operate on foo
}
Than
比
foreach (var foo in AllFoos) {
if (some case where we do want to operate on foo) {
operate on foo
} else if (another case) {
operate on foo
}
}
You can put all of the logic for determining whether or not you want to operate on foo inside your method using yield returns and you foreach loop can be much more concise.
您可以使用 yield 返回将所有用于确定是否要对 foo 进行操作的逻辑放在您的方法中，并且您的 foreach 循环可以更加简洁。
回答by Joel Coehoorn
Lazy Evaluation/Deferred Execution
延迟评估/延迟执行
The "yield return" iterator blocks won't execute anyof the code until you actually call for that specific result. This means they can also be chained together efficiently. Pop quiz: how many times will the following code iterate over the file?
“yield return”迭代器块在您实际调用该特定结果之前不会执行任何代码。这意味着它们也可以有效地链接在一起。小测验：以下代码将在文件上迭代多少次？
var query = File.ReadLines(@"C:\MyFile.txt")
.Where(l => l.Contains("search text") )
.Select(l => int.Parse(l.SubString(5,8))
.Where(i => i > 10 );
int sum=0;
foreach (int value in query)
{
sum += value;
}
The answer is exactly one, and that not until way down in the foreachloop. Even though I have three separate linq operator functions, we still only loop through the contents of the file one time.
答案完全是一个，而且直到foreach循环结束。即使我有三个单独的 linq 操作符函数，我们仍然只循环一次文件的内容。
This has benefits other than performance. For example, I can write a fair simple and genericmethod to read and pre-filter a log file once, and use that same method in several different places, where each use adds on different filters. Thus, I maintain good performance while also efficiently re-using code.
除了性能之外，这还有其他好处。例如，我可以编写一个相当简单和通用的方法来读取和预过滤一次日志文件，并在几个不同的地方使用相同的方法，每次使用都会添加不同的过滤器。因此，我保持了良好的性能，同时还有效地重用了代码。
Infinite Lists
无限列表
See my answer to this question for a good example:
C# fibonacci function returning errors
请参阅我对这个问题的回答以获得一个很好的例子：
C# fibonacci function Returning errors
Basically, I implement the fibonacci sequence using an iterator block that will never stop (at least, not before reaching MaxInt), and then use that implementation in a safe way.
基本上，我使用永远不会停止的迭代器块（至少在达到 MaxInt 之前不会）来实现斐波那契数列，然后以安全的方式使用该实现。
Improved Semantics and separation of concerns
改进的语义和关注点分离
Again using the file example from above, we can now easily separate the code that reads the file from the code that filters out un-needed lines from the code that actually parses the results. That first one, especially, is very re-usable.
再次使用上面的文件示例，我们现在可以轻松地将读取文件的代码与过滤掉不需要的行的代码与实际解析结果的代码分开。尤其是第一个，非常可重用。
This is one of those things that's much harder to explain with prose than it is to just who with a simple visual1:
这是用散文解释比用简单的视觉更难解释的事情之一1：
If you can't see the image, it shows two versions of the same code, with background highlights for different concerns. The linq code has all of the colors nicely grouped, while the traditional imperative code has the colors intermingled. The author argues (and I concur) that this result is typical of using linq vs using imperative code... that linq does a better job organizing your code to have a better flow between sections.
如果您看不到图像，它会显示相同代码的两个版本，背景突出显示不同的问题。linq 代码将所有颜色很好地分组，而传统的命令式代码将颜色混合在一起。作者认为（并且我同意）这个结果是使用 linq 与使用命令式代码的典型结果……linq 在组织代码以在部分之间有更好的流动方面做得更好。
1I believe this to be the original source: https://twitter.com/mariofusco/status/571999216039542784. Also note that this code is Java, but the C# would be similar.
1我相信这是原始来源：https: //twitter.com/mariofusco/status/571999216039542784。另请注意，此代码是 Java，但 C# 将类似。
回答by Daniel Earwicker
Here's my previous accepted answer to exactly the same question:
这是我之前接受的完全相同问题的答案：
Another way to look at iterator methods is that they do the hard work of turning an algorithm "inside out". Consider a parser. It pulls text from a stream, looks for patterns in it and generates a high-level logical description of the content.
看待迭代器方法的另一种方式是它们努力将算法“由内而外”转变。考虑一个解析器。它从流中提取文本，在其中查找模式并生成内容的高级逻辑描述。
Now, I can make this easy for myself as a parser author by taking the SAX approach, in which I have a callback interface that I notify whenever I find the next piece of the pattern. So in the case of SAX, each time I find the start of an element, I call the beginElementmethod, and so on.
现在，作为解析器作者，我可以通过采用 SAX 方法使这件事变得容易，在这种方法中，我有一个回调接口，每当我找到模式的下一部分时，我都会通知它。所以在 SAX 的情况下，每次我找到一个元素的开头时，我都会调用该beginElement方法，依此类推。
But this creates trouble for my users. They have to implement the handler interface and so they have to write a state machine class that responds to the callback methods. This is hard to get right, so the easiest thing to do is use a stock implementation that builds a DOM tree, and then they will have the convenience of being able to walk the tree. But then the whole structure gets buffered up in memory - not good.
但这给我的用户带来了麻烦。他们必须实现处理程序接口，因此他们必须编写一个响应回调方法的状态机类。这很难做到正确，因此最简单的方法是使用构建 DOM 树的 Stock 实现，然后他们将可以方便地遍历树。但是整个结构在内存中被缓冲 - 不好。
But how about instead I write my parser as an iterator method?
但是如何将我的解析器编写为迭代器方法呢？
IEnumerable<LanguageElement> Parse(Stream stream)
{
// imperative code that pulls from the stream and occasionally
// does things like:
yield return new BeginStatement("if");
// and so on...
}
That will be no harder to write than the callback-interface approach - just yield return an object derived from my LanguageElementbase class instead of calling a callback method.
这不会比回调接口方法更难编写 - 只需返回一个从我的LanguageElement基类派生的对象，而不是调用回调方法。
The user can now use foreach to loop through my parser's output, so they get a very convenient imperative programming interface.
用户现在可以使用 foreach 来循环我的解析器的输出，因此他们获得了一个非常方便的命令式编程接口。
The result is that both sides of a custom API look like they're in control, and hence are easier to write and understand.
结果是自定义 API 的双方看起来都在控制之中，因此更容易编写和理解。
回答by Ray
The fine answers here suggest that a benefit of yield returnis that you don't need to create a list; Lists can be expensive. (Also, after a while, you'll find them bulky and inelegant.)
这里的好答案表明，好处yield return是您不需要创建列表；列表可能很昂贵。（此外，一段时间后，您会发现它们笨重且不优雅。）
But what if you don't have a List?
但是如果你没有 List 怎么办？
yield returnallows you to traverse data structures(not necessarily Lists) in a number of ways. For example, if your object is a Tree, you can traverse the nodes in pre- or post- order without creating other lists or changing the underlying data structure.
yield return允许您以多种方式遍历数据结构（不一定是列表）。例如，如果您的对象是一棵树，您可以按前序或后序遍历节点，而无需创建其他列表或更改底层数据结构。
public IEnumerable<T> InOrder()
{
foreach (T k in kids)
foreach (T n in k.InOrder())
yield return n;
yield return (T) this;
}
public IEnumerable<T> PreOrder()
{
yield return (T) this;
foreach (T k in kids)
foreach (T n in k.PreOrder())
yield return n;
}
回答by SPIRiT_1984
Sometimes the sequences you need to return are just too large to fit in the memory. For example, about 3 months ago I took part in a project for data migration between MS SLQ databases. Data was exported in XML format. Yield returnturned out to be quite useful with XmlReader. It made programming quite easier. For example, suppose a file had 1000 Customerelements - if you just read this file into memory, this will require to store all of them in memory at the same time, even if they are handled sequentially. So, you can use iterators in order to traverse the collection one by one. In that case you have to spend just memory for one element.
有时您需要返回的序列太大而无法放入内存。例如，大约3个月前，我参与了一个MS SLQ数据库之间的数据迁移项目。数据以 XML 格式导出。产量返回原来是用非常有用的XmlReader。它使编程变得非常容易。例如，假设一个文件有 1000 个Customer元素——如果你只是将这个文件读入内存，这将需要同时将所有这些元素存储在内存中，即使它们是按顺序处理的。因此，您可以使用迭代器来一一遍历集合。在这种情况下，您只需为一个元素花费内存。
As it turned out, using XmlReaderfor our project was the only way to make the application work - it worked for a long time, but at least it did not hang the entire system and did not raise OutOfMemoryException. Of course, you can work with XmlReaderwithout yield iterators. But iterators made my life much easier (I would not write the code for import so quickly and without troubles). Watch this pagein order to see, how yield iterators are used for solving real problems (not just scientific with infinite sequences).
事实证明，在我们的项目中使用XmlReader是使应用程序工作的唯一方法 - 它工作了很长时间，但至少它没有挂起整个系统，也没有引发OutOfMemoryException。当然，您可以使用XmlReader而无需 yield 迭代器。但是迭代器让我的生活变得更轻松（我不会这么快地编写导入代码并且没有麻烦）。观看此页面以了解如何使用 yield 迭代器解决实际问题（不仅仅是具有无限序列的科学问题）。
回答by Tapas Ranjan Singh
The basic reason for using yield is it generates/returns a list by itself. We can use the returned list for iterating further.
使用 yield 的基本原因是它自己生成/返回一个列表。我们可以使用返回的列表进行进一步迭代。
