On 29.08.2008, at 02:12, Graham Cox wrote:
Well, that was me. But I do see the error of my ways... I guess it was Michael Ash's comment that NSArray *could* change its storage half way through enumeration (if the collection were mutated) that woke me up. I suspect it would only do this if the collection dramatically changed in size but clearly that wouldn't be something to rely on. I checked my own code to make sure I wasn't following my own "advice" anywhere and turns out I've never done it without making a copy anyway.
One other reason why this is dangerous is that NSArray isn't guaranteed to be a plain C-style array, internally.
NSArray is a very abstractly defined collection class. It gives you some performance guarantees for its operations, but beyond that it may choose any implementation it wishes. So, it could actually implement itself as a tree, or a linked list, or a simple C array of pointers, ... or hamsters in a box, for all we care. It could even store the array backwards internally, which would mean that every removal from the end changes all the pointers, while removal from the start would be safe.
Cheers, -- Uli Kusterer "The Witnesses of TeachText are everywhere..." http://www.zathras.de _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
