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:24:26 -0500
oops, sent in what would definetely crash your apps, the LIEing
technique retains the elements rather than just sets them because
otherwise when they do get set and it was released in one place, it
would crash for no longer being valid elsewhere.
The 3rd example should read:
-(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 retain];
newCell->subString = [subString retain];
return newCell;
}
On Mon, 8 Nov 2004 20:04:13 -0500, The Karl Adam <email@hidden> wrote:
> 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