Proper construction of NSFastEnumeration class

I am definitely a beginner when it comes to Objective-C! Any help would be hugely appreciated.

This code works for me, but I really feel like it will certainly blow up on me in the future. For example, what if someone calls autorelease drain in the middle of a for loop. Also, what the heck is the difference between itemPtr and stackbuf? The documentation for NSFastEnumeration on the Apple site is really weak and my code is not behaving as described:

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

That's not very helpful. I'm using only itemsPtr and it works. What exactly am I supposed to do with stackbuf and how should I handle memory allocation/deallocation of stackbuf and itemsPtr??? I read this discussion on macosx-dev (2009-October) Implementing NSFastEnumeration and feel even less confident that I have any idea what is going on.

So... help! Is this right? How do I make it better? What should I be doing with stackBuf? How do I not get in trouble with a break?

Code as a source file: http://vislab-ccom.unh.edu/~schwehr/Classes/2010/mbnutsandbolts/simple-fast-enum2.m (I'm co-teaching this course in C++, but trying to do everything for myself in ObjC)

001: #import <Foundation/Foundation.h>
002: #include <assert.h>
003: 
004: @interface Datagram : NSObject
005: {
006:         int dgId;
007: }
008: -(id)initWithDatagram开发者_StackOverflowType:(int)datagramType;
009: -(void)dealloc;
010: -(NSString *)description;
011: @property (readonly) int dgId;
012: @end
013: 
014: @implementation Datagram
015: @synthesize dgId;
016: - (NSString *)description {
017:         return [NSString stringWithFormat: @"Datagram: dgId:", dgId];
018: }
019: 
020: -(id)initWithDatagramType:(int)datagramType {
021:         self = [super init];
022:         if (!self) return self;
023:         dgId = datagramType; 
024:         return self;
025: }
026: 
027: -(void)dealloc {
028:         NSLog(@"dealloc datagram: %d",dgId);
029:         [super dealloc];
030: }
031: @end
032: 
033: // Pretend sequence of packet ID's coming from a sonar
034: int testSeq[] = {
035:         3, 12, 4, 19, 8, 
036:         2, 2, 2, 2, 2, 2, 2, 2, 2, 9, 
037:         2, 2, 2, 2, 9, 
038:         2,2,2,2,9,
039:         1,2,3,4,5,6,7,8,9,
040:         11,12,13,14,15,16,17,18,19,
041:         3, 
042:         0 // End of sequence / array sentinal
043: };
044: 
045: @interface DatagramFile : NSObject <NSFastEnumeration>
046: {
047:     // No ivars
048: }
049: -(id)init;
050: @end
051: 
052: @implementation DatagramFile
053: -(id)init {
054:     self = [super init];
055:     if (!self) return self;
056:     // NOP
057:     return self;
058: }
059: 
060: - (NSUInteger)countByEnumeratingWithState:(NSFastEnumerationState *)state objects:(id *)stackbuf count:(NSUInteger)len
061: {
062:         NSLog(@"In countByEnumeratingWithState: stackbuf: %p, count: %d", stackbuf, len);
063:         NSLog(@"\t state struct: state=%d %p %p", state->state, state->itemsPtr, state->mutationsPtr);
064:         if (stackbuf) {
065:                 NSLog(@"***INSPECTING STACKBUF\n");
066:                 for(int i=0;i<1000 && stackbuf[i]!=0;i++) {
067:                         NSLog(@"Stackbuf %d: %p",i,stackbuf[i]); // What should I do with stackbuf[i]?
068:                 }
069:         }
070:         if (0 == state->state) {        
071:                 NSLog(@"Initializing loop");
072:                 assert(0==state->itemsPtr);
073:                 state->itemsPtr = malloc(sizeof(id)*16);
074:                 memset(state->itemsPtr, 0, sizeof(id)*16);
075:         } else if (0==len) {
076:                 // Will this get called if the call uses break inside the for loop?
077:                 NSLog(@"Finished loop.  cleanup");
078:                 free(state->itemsPtr);
079:                 state->itemsPtr = 0;
080:         return 0;
081:         }
082:         state->mutationsPtr = (unsigned long *)self; // Tell the caller that the file has not changed
083:         
084:         NSUInteger count=0;
085:         for (; count < len && testSeq[state->state]!=0; count++, state->state++) {
086:                 NSLog(@"Creating datagram of type %d state: %d count %d",testSeq[state->state], state->state, count);
087:                 Datagram *dg = [[Datagram alloc] initWithDatagramType:testSeq[state->state]];
088:                 state->itemsPtr[count] = dg;
089:                 [dg autorelease];
090:         }
091:         NSLog(@"countByEnumeratingWithState read %d datagrams.  state->state: %d",count, state->state);
092:         return count;
093: }
094: @end // implementation DatagramFile
095: 
096: int main (int argc, const char * argv[]) {
097:     NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
098:         
099:     DatagramFile *df = [[DatagramFile alloc] init];
100:     for (Datagram *dg in df) {
101:         NSLog(@"About to read datagram in for");
102:         NSLog(@"  Datagram type: %d", [dg dgId]);
103:     }
104:         
105:     NSLog(@"about to drain pool");
106:     [pool drain];
107:     NSLog(@"pool drained.  ready for winter");
108:     return 0;
109: }

Odd; I’m sure there used to be more comprehensive documentation in The Objective-C Programming Language. Anyway, to answer your concrete question: state->itemsPtr is where you put the actual result. stackbuf and len provide temporary space you can use for this purpose, but you’re not required to. For instance, if your collection uses a straight C array of object references, you can put that in state->itemsPtr directly, and thus return all the objects in one go.

As for your implementation:

• It is never useful to look at the initial contents of stackbuf.
• Instead of malloc()ing a buffer, use stackbuf. Use len instead of a hard-coded 16.
• “Will this get called if the call uses break inside the for loop?” No, it will not. There is no reliable cleanup opportunity.
• As you say, the caller may drain an autorelease pool in the loop. There isn’t a fully “safe” way to deal with the temporary objects in this situation. All you can do is document that the caller mustn’t drain a pool created outside of the iteration within the iteration. In practice, this is unlikely to be a problem.