Re: Best design pattern for un-archiving instances of shared resources?
Re: Best design pattern for un-archiving instances of shared resources?
- Subject: Re: Best design pattern for un-archiving instances of shared resources?
- From: email@hidden
- Date: Sun, 21 Oct 2007 15:45:31 -0700
That's my understanding as well (after several weird cases of
substituted objects being deallocated unexpectedly). If
awakeAfterUsingCoder: releases self and returns an existing object, it
must increment the replacement object's retain count by one before
returning it.
Barry
On 10/21/07, David Spooner <email@hidden> wrote:
>
> On 21-Oct-07, at 1:25 AM, Barry Wark wrote:
> >
> > One last question for the gurus: it appears that awakeAfterUsingCoder
> > should follow the memory management rules of an init method, namely
> > returning a retained object (as opposed to an autoreleased object as
> > you might expect from the standard idiom of methods that do not
> > allocate the object). Can someone confirm this?
> >
>
> The way I understand it is -awakeAfterUsingCoder: is called implicitly
> after -initWithCoder:, so self already has a retain count of one; if
> you return a different object, it must also have a retain count of
> one. Of course if you simply return self, as the default
> implementation does, then you needn't perform an extra retain...
>
> dave
>
>
_______________________________________________
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