Re: memory mgmt in convenience and accessor methods
Re: memory mgmt in convenience and accessor methods
- Subject: Re: memory mgmt in convenience and accessor methods
- From: Daniel Child <email@hidden>
- Date: Tue, 29 May 2007 14:59:32 -0400
If you shouldn't autorelease twice, then where should the autorelease
be to make sure that the variable gets safely kept in the pool? I am
guessing it should be in the simpler method (newThing) since the more
complex one will then automatically receive an autoreleased instance.
(Otherwise it may be released before the more complex one uses it?)
But will the object stay around in memory after it is return from
newThingWithStg?
New approach:
+(id) newThing {
id newThg = [[self alloc] init];
return [newThg autorelease]; // OK TO AUTORELEASE HERE?
}
+(id) newThingWithStg: (int)val {
id newThg = [Thing newThing];
[newThg setInstVar: val];
return newThg; // IS IT GOING TO STAY AROUND LONG ENOUGH?
Or is this entire approach of nesting one constructor within another
unconventional? Thanks.
On May 29, 2007, at 12:54 PM, Clark Cox wrote:
On 5/29/07, Daniel Child <email@hidden> wrote:
Hi All,
I am trying to build some basic test classes and am trying to learn
the appropriate setup for accessors and inits and convenience
methods. While various sources recommend having a "preferred init"
method for each class (the most complicated one), I am wondering if a
similar principle applies to "constructor" (convenience?) methods. Is
the following code ill-advised for any reason? I am in particular
wondering about the double autoreleasing.
+(id) newThing {
id newThg = [[self alloc] init];
return [newThg autorelease];
}
+(id) newThingWithStg: (int)val {
id newThg = [Thing newThing];
[newThg setInstVar: val];
return [newThg autorelease];
You've just autoreleased newThg a second time. Don't do that :)
If the instance vars are primitive types, then retains/releases aren't
even possible, much less required.
OK, thanks.
--
Clark S. Cox III
email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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