Re: object Properties released or autoreleased?
Re: object Properties released or autoreleased?
- Subject: Re: object Properties released or autoreleased?
- From: Andreas Grosam <email@hidden>
- Date: Fri, 16 Jan 2009 18:24:13 +0100
On 16.01.2009, at 14:57, Andy Lee wrote:
On Jan 16, 2009, at 8:46 AM, Dave Keck wrote:
I haven't been following this conversation, but I just happened to
read the last message. Here's a case where release would cause a
crash, but autorelease keeps everything chugging along.
=== Code ===
- (void)setFoo: (id)newFoo
{
[foo autorelease]; // For -someMethod to run without crashing, foo
must be autoreleased
foo = [newFoo retain];
}
If you simply replace the autorelease here with a release, your
implementation of setFoo: is wrong, for the reason you cite. See
the correct ways to implement a setter here:
<http://developer.apple.com/DOCUMENTATION/Cocoa/Conceptual/
MemoryMgmt/Articles/mmAccessorMethods.html>
Regardless of how the setter is implemented, isn't the culprit in the
someMethod method here?
- (void)someMethod
{
id originalFoo = foo; // <-- suspect, since foo's retain count
possibly equals 1
self.foo = anotherFoo; // here, *originalFoo possibly gets
dealocated within the setter
NSLog([originalFoo description]);
}
If GC is enabled, this should work, though.
IMHO, the correct way to implement someMethod in an managed resource
environment (no GC) is as follows:
Since there is no guarantee that the setter or the getter method
extends the livetime temporarily (with autorelease), the caller needs
to care about it, doing this:
- (void)someMethod
{
id originalFoo = [foo retain];
self.foo = anotherFoo;
NSLog([originalFoo description]);
[originalFoo release]
}
The code is not exception-safe. Paranoid or not, I would make it
exception-safe, though because a setter is invoked ("self.foo =
anotherFoo" might possibly fail with an exception).
What are "best practices" for this kind of pattern?
Andreas
--Andy
- (void)someMethod
{
id originalFoo = foo;
self.foo = anotherFoo;
NSLog([originalFoo description]); // <-- CRASH, if we -released in
-setFoo, rather than -autoreleased
}
=== End Code ===
Replacing 'autorelease' in -setFoo with 'release' would cause a crash
in -someMethod, on the NSLog line. Because autorelease delays the
release of 'foo' until the end of the current iteration of the
runloop, -someMethod can still use 'originalFoo' (for the time being)
even after setting self.foo to a new value.
Recently I wrote some multi-threaded memory-management code that
relied on this delayed nature of autorelease to function, because, in
a getter method, I could do:
- (id)someObject
{
return [[someObject retain] autorelease];
}
and the object would be guaranteed to exist through the main thread's
iteration of the runloop, regardless of whether my memory-management
clean-up thread had simultaneously marked the same object for
destruction.
Hope this shows why autorelease can be good :)
(I don't think I'm ever going to get around to using garbage
collection... hah)
David
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Objc-language mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40onlinehome.de
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden