Re: Simple memory problem
Re: Simple memory problem
- Subject: Re: Simple memory problem
- From: Michael Ash <email@hidden>
- Date: Fri, 6 Feb 2009 21:33:11 -0500
On Fri, Feb 6, 2009 at 8:22 PM, Martin Wierschin <email@hidden> wrote:
> The only requirement the method has is to return an object that is valid for
> the caller. Because self is obviously valid, it's a perfectly legitimate
> return value. The fact that the caller releases that string after making the
> call is not any of the method's concern.
Yep. According to the Cocoa memory management guidelines, this,
strictly speaking, is not guaranteed to be safe:
id a = [foo someMethod];
[bar someOtherMethod];
[a someThirdMethod];
You *are* allowed to return objects where the only reference keeping
it alive belongs to the object doing the returning. And you *are*
allowed to destroy objects immediately in your methods. End
conclusion: objects can go away in surprising places.
This isn't to say that you should go sprinkle all of your code with
retain/autorelease pairs. Often you can prove to your own satisfaction
that foo and bar are unrelated, and acting on bar can't affect your
object. But it can be easy to forget, and something like this really
will kill your app:
id a = [dictionary objectForKey:key];
[dictionary setObject:b forKey:key];
[a someMethod];
Be careful out there, boys and girls....
Mike
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden