The implementation of iterators in C# and its consequences (part 1)

C# Yield Keyword « Vasu Balakrishnan’s Blog

C# Yield Keyword « Vasu Balakrishnan’s Blog — Wed, 20 May 2009 22:36:29 GMT

PingBack from http://vasubalakrishnan.wordpress.com/2009/05/20/c-yield-keyword/

Haugerns Development Escapades » Blog Archive » Beware of the IEnumerables

Fri, 17 Oct 2008 12:00:58 GMT

PingBack from http://www.haugern.net/blog/beware-of-the-ienumerables/

Tricky IEnumerable

the blog => anything goes — Thu, 04 Sep 2008 22:44:56 GMT

Implementing IEnumerable<T> can turned out to be tricky in one particular situation. Consider the

re: The implementation of iterators in C# and its consequences (part 1)

Andrew — Fri, 15 Aug 2008 12:41:11 GMT

@CodeMage

> ...By creating a value type that implements the iterator design contract...

Exactly, and that's what bothers me: why didn't they implement 'yield return' to generate structs? Raymond answered above, but it still somehow not quite persuading

(btw - that nested value type iterator should be public, that's possibly something you cannot always afford)

re: The implementation of iterators in C# and its consequences (part 1)

Andrew — Fri, 15 Aug 2008 12:35:28 GMT

[You focused on boxing and missed the original problem. DoSomething2(e) will not resume where DoSomething1(e) left off. And stack overflow is not the issue here either. -Raymond]

Wow! Raymond, yep I missed the point - ultimately had to write a small app in VS to get to it, sorry :)

But. Iterators for List<T> and Dictionary<K,V> are public nested structs. Does this mean that perf gain in foreach loops was more important back then, than the continuation idea (implemented in yield return) ?

(just in case you or someone else here has an explanation)

Thanks,

Andrew

re: The implementation of iterators in C# and its consequences (part 1)

CodeMage — Fri, 15 Aug 2008 04:56:32 GMT

Another interesting fact about iterators is the garbage they generate, by virtue of implementing IEnumerator<T> and IEnumerable<T>. Every time you use an iterator in a foreach loop, you'll instantiate the implementation of these interfaces. In case of yield return, this implementation is hidden from you by the compiler, but it still creates garbage.

There's a way to avoid that, though. By creating a value type that implements the iterator design contract (GetEnumerator, MoveNext, Reset and Current) without implementing the IEnumerator<T> and IEnumerable<T> interfaces, you can still use it in foreach loops but you don't generate any garbage. The bad news is that you have to implement it by hand: there's no syntactic sugar for this.

Iterators

Alexander Morou — Fri, 15 Aug 2008 00:33:14 GMT

As stated before, the primary reason the state machine transitions into a final state is to prevent pre-final states from being repeated, since the logic of them could alter the state of other objects within the iterator's scope (and potentially even cause run-time errors).

I'm guessing the other reason yield break; transitions into a state, is state reduction, the most optimal state machine is the one with the fewest states. Multiple yield breaks do transition into a single state, don't they? (I haven't actually checked.)

Recursive iterators merely require a more complex approach, but are entirely possible. Instead of being directly recursive, you need to cast part of the logic into a sub-iterator that would effectively emit the transition series of objects used in the recursive approach, then using the flat form of the hierarchy, yield the members respectively. Alternatively you can flatten your recursive approach into a non-recursive solution and yield the members that way.

I found iterators interesting because you can essentially do whatever you want with them. My favorite was creating a multi-dimensional array iterator that iterated the indices of an array, yielding the same array instance each time, just with different values. Good for debugging where you send in a nondescript array and its internals are iterated and logged regardless of the array's dimensional structure.

Today’s Blogs « Roman’s Blog

Today’s Blogs « Roman’s Blog — Thu, 14 Aug 2008 23:11:32 GMT

PingBack from http://rhnatiuk.wordpress.com/2008/08/14/todays-blogs/

Interesting Links – 8/14/2008

Matt Johnson's Technical Adventures — Thu, 14 Aug 2008 20:05:09 GMT

Ask the Directory Services Team : MCS Talks Infrastructure Architecture joeware - never stop exploring…

re: The implementation of iterators in C# and its consequences (part 1)

Andrew — Thu, 14 Aug 2008 18:16:42 GMT

[I believe most people expect reference semantics for iterators, not value semantics.]

Vast majority of people writing vernacular C# use them in foreach loops. They never bother about ref/val semantics. Also, you palter a little bit: with a value type enumerator, in your example

e = o.GetEnumerator();

DoSomething1(e);

DoSomething2(e);

e gets boxed, so no difference between a class and a struct iterator. The only benefit for a value type iterator comes from the foreach loop: it uses duck typing against iterators, thus doesn't cast to IEnumerator.

[...I don't see how nesting is involved]

Um, sorry - I meant recursion. If you recursively interate through, all iterators (as far as I understand) should be on the stack that might, eg. cause stack overflow.

[You focused on boxing and missed the original problem. DoSomething2(e) will not resume where DoSomething1(e) left off. And stack overflow is not the issue here either. -Raymond]