mikeash.com pyblog/friday-qa-2010-04-16-implementing-fast-enumeration.html comments

Dave MacLachlan - 2025-09-28 01:42:48

Sun, 28 Sep 2025 01:42:48 GMT

And how about one more edit...



state->mutationsPtr = &state->state;

Dave MacLachlan - 2025-09-27 21:20:17

Sat, 27 Sep 2025 21:20:17 GMT

Actually my comment above is bad (should have tested before I did anything). Can't take the address of an rvalue. Sigh...and mutationsPtr can't be nil. So how about:



state->mutationsPtr = (unsigned long *)&enumerationState;

That should be constant across calls.

Dave MacLachlan - 2025-09-27 21:08:36

Sat, 27 Sep 2025 21:08:36 GMT

So with refcounts being stored in the isa pointer, I don't think that:



state->mutationsPtr = (unsigned long *)self;

works anymore. It would seem that an added ref could make it appear that we had mutated things. Given your description of how the system works, either we want it set to something like



state->mutationsPtr = (unsigned long *)&self;

or maybe not set it to anything at all unless we have a real use for it?

Chris Chandler - 2013-07-05 21:36:07

Fri, 05 Jul 2013 21:36:07 GMT

Mike, do you (or any of your readers) know what happens when the body in

    for(id obj in collection)

    {

        // body

    }

contains a break statement? What does your suggested implementation look like with break support?

Specifically, does [NSFastEnumeration countByEnumeratingWithState: objects: count:] get called with a special state value to indicate the end of the enumeration?

Regarding your point about temporary objects, that problem could be solved if the function was always called one more time with a special state value at the end of the enumeration, to give the implementation a chance to clean itself up, after retaining its objects in the first place. One wonders whether Apple has thought of that, and if not, whether a bug should be filed!

Denis Halabuzar - 2013-03-15 10:21:43

Fri, 15 Mar 2013 10:21:43 GMT

ah, sorry, didn't read the line "mutationsPtrValue != *state.mutationsPtr" carefully

Denis Halabuzar - 2013-03-15 10:18:40

Fri, 15 Mar 2013 10:18:40 GMT

hm, by some unknown to me reason compiler tries to read memory pointed by mutationsPtr. (i tried to store element count there).

Heath Borders - 2011-06-14 04:50:31

Tue, 14 Jun 2011 04:50:31 GMT

For anyone interested, I've made a series of blocks-based categories that rely on NSFastEnumeration for their implementation. I used this article as a reference. I'd appreciate any comments anyone has.

https://github.com/hborders/HBCollections

mikeash - 2010-04-25 16:05:28

Sun, 25 Apr 2010 16:05:28 GMT

Yes, return 0; is what I meant to write there. NULL will work, but is ugly.

As for the documentation question, I agree, it looks wrong. stackbuf is just a convenient storage, and the sender won't iterate over it unless you tell it to.

Ling - 2010-04-19 04:02:26

Mon, 19 Apr 2010 04:02:26 GMT

One question about the Apple doc:

stackbuf
A C array of objects over which the sender is to iterate.

itemsPtr
A C array of objects.

I think the doc is very confusing, or right down wrong. It tells you that it is stackbuf that the sender is to iterate but in fact it it state ->itemsPtr. In fact, you can completely ignore stackbuf in your implementation and use an internal data structure to back up state ->itemsPtr.

Ling - 2010-04-19 03:43:21

Mon, 19 Apr 2010 03:43:21 GMT

I think you mean "return 0" here:



        if(!currentNode)

            return NULL

mikeash - 2010-04-19 01:01:40

Mon, 19 Apr 2010 01:01:40 GMT

Thanks for pointing that out. HTMLification gone wrong. I've fixed it now.

Michael Babin - 2010-04-18 15:44:29

Sun, 18 Apr 2010 15:44:29 GMT

In the "Returning One Object At a Time" example:



        // otherwise, point itemsPtr at the node's value

        state->itemsPtr = &currentNode-;>value

Believe there is a superfluous semi-colon there.

Thanks for the article and the entire series.

Skirwan - 2010-04-18 03:22:35

Sun, 18 Apr 2010 03:22:35 GMT

That's what I get for running my mouth at a higher clock than my brain. Apologies.

mikeash - 2010-04-16 19:53:53

Fri, 16 Apr 2010 19:53:53 GMT

Aaron: You are correct, fixed, and thanks.

Skirwan: It would be nice if people would check these claims before making them. Mac OS X uses LP64, which means that long is 64 bits. That is the precise reason why these fields are of type long.

Charles Parnot - 2010-04-16 19:43:55

Fri, 16 Apr 2010 19:43:55 GMT

Skirwan: actually, I believe longs are 64-bit on Mac OS X (when compiling for 64 bits), see LP64 on this web page:
http://developer.apple.com/macosx/64bit.html

Skirwan - 2010-04-16 19:23:31

Fri, 16 Apr 2010 19:23:31 GMT

It's probably worth noting that many of the examples aren't 64-bit clean -- extra[0] isn't going to hold a 64-bit pointer without some backup from extra[1]. (Not to imply that I think you don't realize that, just that folks who find the page by Googling may need the reminder).

Aaron - 2010-04-16 18:42:50

Fri, 16 Apr 2010 18:42:50 GMT

I think you mean:

firstLoop = NO;

in the while loop example.