Re: Crash when calling custom methods in custom subclass.
Re: Crash when calling custom methods in custom subclass.
- Subject: Re: Crash when calling custom methods in custom subclass.
- From: mmalcolm crawford <email@hidden>
- Date: Sat, 30 Jul 2005 22:23:18 -0700
On Jul 30, 2005, at 4:51 PM, Adam Raney wrote:
- (id) init
{
[super init];
if (self) {
_format = [NSString string];
_content = [NSString string];
_answers = [NSMutableArray array];
_isHeader = NO;
}
return self;
}
The instance variables you create here are all autoreleased and will
all be invalid after the first event loop (when the autorelease pool
is released)...
When I remove the setAnswers: method call, the addHeaderRow: method
completes with no problem. When the setAnswers: call included, the
entire addHeaderRow: method completes (the setAnswers: works as
expected), then I get the "EXC_BAD_ACCESS" error and the program
crashes.
[...]
- (void) setAnswers: (NSArray *)newAnswers
{
if (newAnswers != _answers) {
[_answers autorelease];
_answers = [newAnswers copy];
}
}
... so _answers receives two release messages and causes the crash.
If you want to set variables in the initializer, they must also abide
by the memory management rules, for example:
[self setFormat:[NSString string]];
[self setContet:[NSString string]];
[self setAnswers:[NSMutableArray array]];
although in general it is more efficient to use a local variable and
alloc and init, then release the variable after the assignment, like
this:
NSString *newString = [[NSString alloc] init];
[self setFormat:newString];
[newString release];
That said, premature optimisation is also a bad thing:
I can get AROUND this problem by making the array mutable, and using
addObject: calls, but I have read that Mutable Arrays create more
memory overhead and are less effecient.
Should the content be changed or not? If it should, then it's
appropriate to make it mutable. In general, there's no need for this
sort of optimisation unless a profiling tool shows it's warranted...
mmalc
_______________________________________________
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