Re: Should I retain a variable returned from this accessor?
Re: Should I retain a variable returned from this accessor?
- Subject: Re: Should I retain a variable returned from this accessor?
- From: Negm-Awad Amin <email@hidden>
- Date: Tue, 12 Aug 2008 11:12:55 +0200
Am Di,12.08.2008 um 04:51 schrieb Peter N Lewis:
At 4:48 PM -0400 11/8/08, Kyle Sluder wrote:
On Mon, Aug 11, 2008 at 3:12 PM, Sean DeNigris
<email@hidden> wrote:
Hi, how do I handle memory management for todoUid below? Do I
have to
retain or autorelease it?
[...snip...]
// Get uid to return
NSString* todoUid = [newTodo uid];
[...snip...]
return todoUid;
}
http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Tasks/MemoryManagementRules.html
You've gotten todoUid from a method that is not +alloc and does not
begin with +new or contain -copy, so you do not own it. Therefore
you
must -retain it if you want to hold on to it beyond "now". Since you
don't, just let it go, it's not your responsibility.
That's it. Done.
I'm no Cocoa expert, but I think you're wrong on this, you've missed
out a crucial line:
At 3:12 PM -0400 11/8/08, Sean DeNigris wrote:
// Get uid to return
NSString* todoUid = [newTodo uid];
// Clean up
[newTodo release];
newTodo = nil;
return todoUid;
[newTodo release] is not [newTodo autorelease]. So it may
immediately call dealloc and dealloc the uid returned by by [newTodo
uid]. To avoid this, you could do:
NSString* todoUid = [[[newTodo uid] retain] autorelease];
It is quite possible that [newTodo uid] does exactly the above, but
it might just return the internal ivar. If this is not true, I
would very much like to be corrected!
Advice on this list that I think is good advice is to always use
autorelease unless there is really good reason not to
YES! Many, many of memory managemt problems are solved with this
technique. BTW: You can do the same inside a getter to get rid of
thread problems.
(eg, with a large number of objects in a loop).
A -retain (+alloc, +new) release pair is no solution even in that
situation, because nobody knows, whether the newly allocated object
uses -autorelease itself. So with an immediate -release you get rid
of the "top level" instances, but not of the related ones.
for( … ) // 10.000.000 times
{
id instance = [[Instance alloc] init]; // allocates 10 helper
instances, autoreleased
// Do something
[instance release]; // helpers are still alive!
}
The only working solution is to drain a new ARP inside the loop.
Amin
Then you would solve your problem like this:
- (NSString*) saveToiCalTodo: (NSString*) theSummary : (id)
theDescription
{
// Create new iCal todo
iCalTodo* newTodo = [[[[iCal classForScriptingClass:@"todo"] alloc]
init] autorelease];
// Add the todo to my iCal calendar
[[myCalendar todos] addObject:newTodo];
// Set its summary
[newTodo setSummary:theSummary];
// Store description
[newTodo setObjectDescription: theDescription];
// Get uid to return
NSString* todoUid = [newTodo uid];
return todoUid;
}
By using autorelease when you alloc the object, you avoid a bunch of
possible bugs and simplify your code.
Now:
* if you return early for any reason, newTodo wont leak
* todoUid remains valid at least until newTodo is released by the
autorelease pool
* Your code has less memory management routines cluttering it up and
so is clearer and more appropriate for GC.
But as I say, I'm no Cocoa expert, so I could be wrong.
Enjoy,
Peter.
--
Keyboard Maestro 3 Now Available!
Now With Status Menu triggers!
Keyboard Maestro <http://www.keyboardmaestro.com/> Macros for your Mac
<http://www.stairways.com/> <http://download.stairways.com/>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden
Amin Negm-Awad
email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden