Re: Overriding -copyWithZone: the right way
Re: Overriding -copyWithZone: the right way
- Subject: Re: Overriding -copyWithZone: the right way
- From: The Karl Adam <email@hidden>
- Date: Mon, 8 Nov 2004 20:04:13 -0500
Not to rain on the parade but NSCopying does explain that you should
implement this method with one of the three available ways.
1. Super implements it and you want a deep copy. So you call [super
allocWithZone:] and use the memory selectors to set the elements that
your subclass adds.
ie.
-(id) copyWithZone: (NSZone*)zone {
MyClass *newCell = (MyClass *)[super copyWithZone:zone]; // you
need to cast up to your subclass
// then set your memory state using the memory selectors and copy
newCell->font = [font copy];
newCell->subString = [subString copy];
return newCell;
}
2. Your super does not implement it. So you manually call [[self
allocWithZone:] init] and use the set/get methods to set your state.
-(id) copyWithZone: (NSZone*)zone {
MyClass *newCell = [[self allocWithZone:zone] init]; // we know
how to do this thanks to NSObject
// then set your memory state using the set/get methods we made
// Depending on teh implementation of your class these will most
likely be shallow copies
// Unless your mutators copy incoming state and return copies of
internal state to
// provide another level of encapsulation
[newCell setFont:font];
[newCell setSubString:subString];
return newCell;
}
3. And last but not least, LIE. To be honest cells are supposed to be
lightweight and fast so why spend time copying immutable state
variables, instead we just point to the ones we already have?
-(id) copyWithZone: (NSZone*)zone {
MyClass *newCell = (MyClass *)[super copyWithZone:zone]; // you
need to cast up to your subclass
// then set your memory state using the memory selectors and point to
what you already have
newCell->font = font;
newCell->subString = subString;
return newCell;
}
The last method is good since it's MUCH faster and NSCells are
instantiated then their -setObjectValue: is called so this gets
changed anyway. However, this also lets you know when something is
wrong since all your cells look the same and have the same info for
whatever reason that is probably -willDisplayCell related. Yea, i
make a lot of custom cells.
On Sat, 6 Nov 2004 16:50:01 +0100, M. Uli Kusterer
<email@hidden> wrote:
> At 15:39 Uhr -0800 05.11.2004, Byron Wright wrote:
> >Why don't you check the crash log or run the application in the
> >debugger until it crashes. You'll get a stack trace from which will
> >help you pinpoint the problem.
>
> Though with memory bugs, the time at which you see the crash might
> not be the time at which the actual bug occurred. If you overwrite
> some memory, and it's still within your app's allocated range of
> addresses, you won't notice until you next attempt to use the
> overwritten data.
>
> Most "weird" crashes are memory-related.
> --
>
>
> Cheers,
> M. Uli Kusterer
> ------------------------------------------------------------
> "The Witnesses of TeachText are everywhere..."
> http://www.zathras.de
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Cocoa-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden