Some (or most) people might be aware of this caveat, but I was not, so
I'll share it.
Consider this code:
NSArray *array = [NSArray arrayWithObjects:[MyCounterClass
newObject], [MyCounterClass newObject], nil];
where [MyCounterClass newObject] is a static method that returns a new
autoreleased instance that simply stores an incrementing int32 counter
in its instance variable, e.g.
self.oid = SomeStaticCounter++; // (or ideally,
OSAtomicIncrement32Barrier(&SomeStaticCounter);
Now, one would expect that the array would contain:
element 1: MyCounterInstance.oid=1
element 2: MyCounterInstance.oid=2
However, this is NOT the case. Either the compiler or the runtime
executes the SECOND call to [MyCounterClass newObject] FIRST, so the
array actually contains:
element 1: MyCounterInstance.oid=2
element 2: MyCounterInstance.oid=1
NSArray arrayWithObjects: is of course correctly putting the objects
into the array in the correct natural ordering, but the objects are
CREATED on the stack in the oppose order. Maybe most people knew
that, I did not. So the (or a) workaround is:
MyCounterClass *object1 = [MyCounterClass newObject];
MyCounterClass *object2 = [MyCounterClass newObject];
NSArray *array = [NSArray arrayWithObjects: object1, object2, nil];
- Eric
_______________________________________________
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 arch...@mail-archive.com
