The fast enumeration solution takes advantage of two facts: -countByEnumeratingWithState: is given a chunk of space that can hold a number of pointers. Empirically, it looks like Cocoa provides 16 pointers worth of space.
I am assuming the 16 pointers provides the initial value of ‘len’ in the program. Can you confirm that is how this is suppose to be interpreted?
I am so use to initializations that this seems to be an initialization of data that occurs behind the scenes as a result of the method in the protocol being used or implemented.
Maybe is this the reason why you used the word “empirically” ?
Would it also be technically correct to say : The first invocation of the -countByEnumeratingWithState on MacOS intializes ‘len’ with a value of 16. This could be implementation dependent.
I hope I am not reading to much into this… but it is good example that you put forth
Thanks! I’m proud of that one because it’s so weird.
So yes, the value of ‘len’ is how much stack space the fast enumeration machinery is giving you for your use. The current values of the pointers on the stack are undefined, which is why you have to return the number of pointers returned from the method. You fill them in with whatever values, and then pull out the values inside of the for loop. The empirical checking was NSLog (@"%ld", len);
And that statement s a correct one - apple’s got the power to change the default at any time, but currently it’s 16 pointers, or 128 bytes on the desktop.
If you’re interested in fast enumeration, I have a three-parter that goes into more detail:
Thanks for the reply Mark… and especially the links… part 2 is exactly what I was looking for.
Two things came to mind …
Thing #1
The fact that this is fast enumeration and and provides a stack for general use made me that this protocol could be used for a high speed matrix stack for OpenGL. Push your matrix
on the stack and enumerate and retrieve when you need it…
And … maybe run multiple objects with the Fast Enumeration protocol … on different threads… utilize different CPU cores to get performance…
Thing #2
This might need to go into the Dtrace thread/forum but I was curious if you have ever probed a method from a protocol getting called?..
You can put probes on stuff that actually exists, like the adopting of protocols which have a backing implementation (vs say a superclass taking care of it).
You can get a listing of all of them by using a dtrace trick I picked up recently. Use -l (dash ell - make a list) and -c (run the program and feed the pid back in $target) to get a listing of matching probes, without actually running anything. Very handy for getting more concrete lists of what’s available with the pid and objc providers.
Back on the discussion of -countByEnumerationWithState I wanted to add some thoughts on the following verbiage:
[quote]The generator uses the stack space for pointers to NSNumbers for the sequence of numbers and uses the scratch space to hold
the N-1 and N-2 values of the sequence[/quote]
Some additional subtle observations … The enumeration is fast because of the given array of pointers. This comes into play when you implement the scanning pointers.
All incrementing is done through pointer arithmetic which is suppose to be provide better performance. Initially I just appreciated having the “scratch workspace” but now I realize the importance of using the array of pointers in addition to the unsigned long * extra[5] data resource. The two in tandem are a powerful combination.
As you have mentioned there is a lot that under the hood in the implementation of Apple Frameworks that we don’t know about. But I have a hunch under the hood this type of implementation might be used in a lot of places that might not be apparent…
I hope my pointer performance observation is the right hunch…
