> On Feb 8, 2016, at 1:47 PM, Alex Zavatone <z...@mac.com> wrote:
>
> if ( [myIVar respondsToSelector:@selector(someMethod)] {
> EXC_BAD_ACCESS (code=1, address=0x143545358)
> I did a po on myiVar and I get an address or 0x000000014f05ee00
0x143545358 is probably the (bogus) class-info pointer it got from the object’s
‘isa’ pointer. So in this case the myIVar pointer itself isn’t itself obviously
bad, but it is pointing to garbage. Most likely it used to be a valid object
but was dealloced and the memory’s been reused for something else.
NSZombieEnabled is the obvious thing to try here. And/or the address sanitizer.
> Also, I'd prefer to use the property not the iVar as I've found these much
> safer in the past for accessing internal objects without causing access
> issues.
> Am I correct here?
I always use ivars because it’s much more efficient in code size and clock
cycles. The only case where using ivars directly can bite you is if either the
ivar or the property will be modified on another thread, since ARC’s inlined
setter code isn't thread-safe.
But I always prefix ivars with an underscore to make it obvious that they have
different scope from locals.
—Jens
_______________________________________________
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
