On May 7, 2010, at 11:34 AM, "Patrick M. Rutkowski"
<rutsk...@gmail.com> wrote:
Will NSObject's init method ever really return nil?
Realistically, no. If it does, there's nothing you can do about it,
and you might as well abort. You've probably run out of memory, and I
don't believe there's any guarantee that the runtime will be in a
consistent state if it can't allocate any objects. I could be wrong
about that, but I still wouldn't recommend it.
E.g. if I sub-class NSObject, then is it worth checking for nil after
doing self = [super init]?
I say yes for the sake of muscle memory. I like to combine them into
one statement: if(!(self = [super init])) return nil;
-init will be called a maximum of once per object. It's worth the
branch to check for this case, if for no other reason than to avoid
crashing on NULL pointer dereference. You can even use the GCC branch
prediction intrinsics to minimize the impact of the branch.
My $0.02 (worth more in Europe every day!)
--Kyle Sluder
_______________________________________________
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
