Re: Problem Archiving/Un-archiving Custom Objects

[Dave]

Thanks a lot for the clarification…..
___

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

Re: Problem Archiving/Un-archiving Custom Objects

[Dave]

> On 21 Jan 2016, at 23:40, Quincey Morris 
>  wrote:
> 
> On Jan 21, 2016, at 15:22 , Dave  > wrote:
>> 
>> I’m relying of the copy attribute for the NSString’s, do I need to change 
>> these to do a [xxx 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)

Thanks again,
All the Best
Dave



___

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

Re: Problem Archiving/Un-archiving Custom Objects

[Clark S. Cox III]

> On Jan 22, 2016, at 06:14, Dave  wrote:
> 
> 
>> On 21 Jan 2016, at 23:40, Quincey Morris 
>>  wrote:
>> 
>> On Jan 21, 2016, at 15:22 , Dave > > wrote:
>>> 
>>> I’m relying of the copy attribute for the NSString’s, do I need to change 
>>> these to do a [xxx 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)

The -copy method is called twice, but what that means in practical terms 
depends on the object being copied.
If you're talking about NSString specifically, zero copies get created, as 
-copy on immutable foundation types is equivalent to -retain (or is a no-op 
under ARC).

If "anotherString" is an NSMutableString, then one copy will be created by the 
explicit call to -copy in your example. But that copy will, itself, be an 
immutable NSString, so the second copy will be a no-op.

And, of course, if we were talking about some other class that doesn't have a 
similar optimization, two copies will be created.

Regardless of the circumstances, that explicit copy is redundant (but harmless) 
under ARC, and will cause a memory leak under MRR.
___

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

Re: Problem Archiving/Un-archiving Custom Objects

[Kyle Sluder]

On Fri, Jan 22, 2016, at 08:14 AM, Dave wrote:
> 
> > On 21 Jan 2016, at 23:40, Quincey Morris 
> >  wrote:
> > 
> > On Jan 21, 2016, at 15:22 , Dave  > > wrote:
> >> 
> >> I’m relying of the copy attribute for the NSString’s, do I need to change 
> >> these to do a [xxx 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 (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

Re: Problem Archiving/Un-archiving Custom Objects

[Clark S. Cox III]

> On Jan 22, 2016, at 06:14, Dave  wrote:
> 
> 
>> On 21 Jan 2016, at 23:40, Quincey Morris 
>>  wrote:
>> 
>> On Jan 21, 2016, at 15:22 , Dave > > wrote:
>>> 
>>> I’m relying of the copy attribute for the NSString’s, do I need to change 
>>> these to do a [xxx 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)

The -copy method is called twice, but what that means in practical terms 
depends on the object being copied.
If you're talking about NSString specifically, zero copies get created, as 
-copy on immutable foundation types is equivalent to -retain (or is a no-op 
under ARC).

If "anotherString" is an NSMutableString, then one copy will be created by the 
explicit call to -copy in your example. But that copy will, itself, be an 
immutable NSString, so the second copy will be a no-op.

And, of course, if we were talking about some other class that doesn't have a 
similar optimization, two copies will be created.

Regardless of the circumstances, that explicit copy is redundant (but harmless) 
under ARC, and will cause a memory leak under MRR.
___

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

Re: Problem Archiving/Un-archiving Custom Objects

[Dave]

> On 21 Jan 2016, at 23:04, Quincey Morris 
>  wrote:
> 
> On Jan 21, 2016, at 13:47 , Dave  > wrote:
>> 
>> myObjectCopy. pNodeIndexPath = self. pNodeIndexPath; //Copy 
>> Attribute on Property
> 
> You have to be careful, depending on what’s already happened. If the object 
> was copied with NSCopyObject, which might have happened in NSObjet’s 
> copyWithZone method even if you didn’t call it directly, instance variables 
> will contain valid but unretained pointers. Because you’re assigning to a 
> property, the existing underlying instance variable will have its retain 
> count decremented, which probably isn’t the right thing to do.
> 
> Your copyWithZone method is more like an init method than a regular method. 
> In general, like in inits, you will want to assign directly to instance 
> variables rather than use property setters. In addition, you may have to deal 
> manually with retain counts. 
> 
> Yes, copyWithZone is a potential nightmare. In many cases, it’s easier not to 
> copy anything really, but to create a new object whose instance variables you 
> set up in a proper ‘initAsCopyOf:’ method that follows normal init 
> conventions.
> 

Yes, I came to that conclusion too and I added a initWithIndexPath method to an 
NSIndexPath Category and it works!

I was manually copying the dictionaries and arrays anyway - [x mutableCopy];

I did that and Bang it Crashed about, but this time with another bug which was 
easy to find since malloc guard caught it this time, that one was a flakey 
method for converting an NSString “xx.yy.zz" type string an Array of 
NSUInteger’s to call initWithIndexs with!

Fixed that one and now it work!

Thanks a lot Jens and Qunicey………

One quick question, I’m relying of the copy attribute for the NSString’s, do I 
need to change these to do a [xxx copy] too or is NSString OK?

All the Best
Dave
 
___

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

Problem Archiving/Un-archiving Custom Objects

[Dave]

Hi,

I’ve got it working using NSCoding for now and I can review to later.

I have one crashing problem though, I’m getting a crash when one of the 
properties in my LTWNodeInfo is dealloc. It’s an NSIndexPath class, the rest 
seem to be ok. i’m wondering if it is to do with the way in which I’m 
creating/copying it:



@property (nonatomic,copy)  NSIndexPath*
pNodeIndexPath;


in initWithCoder:

self.pNodeIndexPath = [theCoder decodeObjectForKey:@"pNodeIndexPath”];


in encodeWithCoder:

[theCoder encodeObject:self. pNodeIndexPath forKey:@"pNodeIndexPath”];

in copyWithZone:

myObjectCopy. pNodeIndexPath = self. pNodeIndexPath;//Copy 
Attribute on Property



In order to work around it, I added an extra property:

@property (nonatomic,copy)  NSString*   
pNodeIndexPathString;


Added to: initWithCoder:

self.pNodeIndexPathString = [theCoder 
decodeObjectForKey:@"pNodeIndexPathString”];

myIndexPath = [NSIndexPath 
newIndexPathWithPathString:self.pUIElementInfoIndexPathString];
self.pUIElementInfoIndexPath = myIndexPath;


Added to: encodeWithCoder:

[theCoder encodeObject:self. pNodeIndexPathString 
forKey:@"pNodeIndexPathString”];

and removed the encodeObject: self.pNodeIndexPath

in copyWithZone:


myObjectCopy. pNodeIndexPath = self. pNodeIndexPath;
//Copy Attribute on Property
myObjectCopy. pNodeIndexPathString = self. pNodeIndexPathString;
//Copy Attribute on Property

But I still get a crash on the dealloc of pNodeIndexPath. 

in dealloc:

self.pNodeIndexPath = nil;

Anyone have any ideas what I’m doing wrong?

Thanks in Advance
Dave



___

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

Re: Problem Archiving/Un-archiving Custom Objects

[Graham Cox]

> On 22 Jan 2016, at 10:04 AM, Quincey Morris 
>  wrote:
> 
> In general, like in inits, you will want to assign directly to instance 
> variables rather than use property setters


Same applies to -initWithCoder: If you call a lot of property setters there, 
performance is slow. It might not matter, but for big graphs (10,000+ objects) 
it can be a killer. If any setters have side effects it can be suicidal.


—Graham
___

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

Re: Problem Archiving/Un-archiving Custom Objects

[Quincey Morris]

On Jan 21, 2016, at 13:47 , Dave  wrote:
> 
> myObjectCopy. pNodeIndexPath = self. pNodeIndexPath;  //Copy 
> Attribute on Property

You have to be careful, depending on what’s already happened. If the object was 
copied with NSCopyObject, which might have happened in NSObjet’s copyWithZone 
method even if you didn’t call it directly, instance variables will contain 
valid but unretained pointers. Because you’re assigning to a property, the 
existing underlying instance variable will have its retain count decremented, 
which probably isn’t the right thing to do.

Your copyWithZone method is more like an init method than a regular method. In 
general, like in inits, you will want to assign directly to instance variables 
rather than use property setters. In addition, you may have to deal manually 
with retain counts. 

Yes, copyWithZone is a potential nightmare. In many cases, it’s easier not to 
copy anything really, but to create a new object whose instance variables you 
set up in a proper ‘initAsCopyOf:’ method that follows normal init conventions.

___

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

Re: Problem Archiving/Un-archiving Custom Objects

[Quincey Morris]

On Jan 21, 2016, at 15:22 , Dave  wrote:
> 
> I’m relying of the copy attribute for the NSString’s, do I need to change 
> these to do a [xxx 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.

___

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

Re: Problem Archiving/Un-archiving Custom Objects

[Jens Alfke]

No, that’s weird, your code looks ok to me.
Have you tried using the static analyzer? Or the address sanitizer? Or running 
with NSZombies?

—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