Re: Problem Archiving/Un-archiving Custom Objects
Re: Problem Archiving/Un-archiving Custom Objects
- Subject: Re: Problem Archiving/Un-archiving Custom Objects
- From: Kyle Sluder <email@hidden>
- Date: Fri, 22 Jan 2016 09:32:23 -0600
On Fri, Jan 22, 2016, at 08:14 AM, Dave wrote:
>
> > On 21 Jan 2016, at 23:40, Quincey Morris <email@hidden> wrote:
> >
> > On Jan 21, 2016, at 15:22 , Dave <email@hidden <mailto:email@hidden>> wrote:
> >>
> >> I’m relying of the copy attribute for the NSString’s, do I need to change these to do a [xxxxxxx copy] too
> >
> > If you’re writing the setter yourself, you must do the copy yourself. If you’re using the synthesized setter, it’s done for you.
> >
> > In your own code, you may as well be liberal with ‘copy’. It’s basically free (in run-time cost) in situations where you don’t need it. You don’t save anything by leaving it out.
> >
>
> I’ve always been confused over what *actually* happens when you do
> something like this:
>
> @property (copy) NSString* pString;
>
>
> self.pString = [anotherString copy];
>
> Do two new NSString objects get created? (I mean using the synthesized
> setter)
No. -copy is equivalent to -retain for immutable strings, so in the best
case this code causes zero copies (when anotherString is immutable), and
in the worst case it causes one (when anotherString is mutable).
--Kyle Sluder
_______________________________________________
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