正确构造NSFastEnumeration类 [英] Proper construction of NSFastEnumeration class
问题描述
关于Objective-C，我绝对是一个初学者！任何帮助将不胜感激。
I am definitely a beginner when it comes to Objective-C! Any help would be hugely appreciated.
此代码对我有用，但我真的觉得将来肯定会被炸毁。例如，如果有人在for循环中间调用自动释放流失怎么办。另外，itemPtr和stackbuf之间的区别是什么？ Apple网站上有关NSFastEnumeration的文档确实很薄弱，我的代码却没有如下所述：
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那不是很有用。我只使用itemsPtr，它可以正常工作。我应该用stackbuf做什么，如何处理stackbuf和itemsPtr的内存分配/取消分配？？？我在macosx-dev（2009年10月）上阅读了此讨论，正在实施NSFastEnumeration，甚至对我有什么想法都没有信心。
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.
所以...帮助！这是正确的吗？我如何做得更好？我应该用stackBuf做什么？我怎么不会在休息时遇到麻烦？
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?
作为源文件的代码： http://vislab-ccom.unh.edu/~schwehr/Classes/2010/mbnutsandbolts/simple-fast-enum2.m （我是用C ++教授本课程，但尝试在ObjC中为自己做所有事情）
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)initWithDatagramType:(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: }
推荐答案
奇数；我确定 Objective-C编程语言 。无论如何，要回答您的具体问题： state-> itemsPtr 是放置实际结果的位置。 stackbuf 和 len 提供了可用于此目的的临时空间，但不是必需的。例如，如果您的集合使用对象引用的直接C数组，则可以将其直接放在 state-> itemsPtr 中，从而一次性返回所有对象。
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.
关于您的实现：
- 查看
stackbuf的初始内容。 - 代替
malloc（）来创建缓冲区，请使用stackbuf。使用len而不是硬编码的16。 - 如果该调用在for循环内使用break，会被调用吗？不，不会。没有可靠的清理机会。
- 正如您所说，调用者可能会在循环中耗尽自动释放池。在这种情况下，没有一种完全安全的方式来处理临时对象。您所要做的就是记录调用者一定不要耗尽在迭代过程中在迭代之外创建的池。实际上，这不太可能成为问题。
- It is never useful to look at the initial contents of
stackbuf. - Instead of
malloc()ing a buffer, usestackbuf. Useleninstead 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.
这篇关于正确构造NSFastEnumeration类的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
