> The question is: Is it documented as a fact you can rely on that this is > the case? If not, I at least wouldn't rely on it for shipping code. Even > if it was for an "at home" project I'd think about it long and hard. > Tracking down subtle memory bugs caused by Apple deciding to move the > reference count into an NSObject instance variable after all doesn't > sound like a fun occupation.
That wouldn't matter if you ensure that, when you execute *b = *a, the retain counts of the two objects are the same. What would cause a problem would be if NSObject contained a hidden iVar pointing to something else containing the retain count. Then, when you copy this pointer, the retain counts of a and b become 'linked' and ultimately, all instances of the object end up sharing the retain count of the 'clean instance' one is copying from when zeroing out the object for reuse. Even then, all is not lost. Override retain and release to do nothing. Presumably, Ben, you have your own scheme for managing the lifecycle of these objects which is not based on retain counts. I must stop with this! I'm supposed to be working! Paul Sanders. _______________________________________________ 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
