Re: Appropriate dealloc and finalize actions
Re: Appropriate dealloc and finalize actions
- Subject: Re: Appropriate dealloc and finalize actions
- From: Kai Brüning <email@hidden>
- Date: Mon, 12 Oct 2009 14:29:46 +0200
On 12.10.2009, at 13:42, Roland King wrote:
On 12-Oct-2009, at 7:26 PM, Karolis Ramanauskas wrote:
Thanks, Kai, Greg, Jens,
It's generally a bad idea to have two objects each retain the
other. It
produces a reference loop, which means neither object can be
deallocated
without manually releasing each side of the relationship.
As was stated in my original email these are all weak references:
@property (readwrite, assign) MyClass * connection;
I am not retaining the other object. In fact I couldn't really do
it because
I'm pointing to the object of the SAME class.
yes you could - nothing stops you in retain/release mode from
retaining an object of the same class, or even yourself, multiple
times.
MyClass 1 ----> MyClass 2
MyClass 2 ----> MyClass 1
If I made a property to retain the value it would automatically
mean that I
get a retain cycle.
indeed you would one you would have to break.
So whenever either an input or output is deleted I have to nil the
connection of the object pointing to the soon to be deallocated
object:
self.connection.connection = nil;
Yes that looks like it would work, you explicitly remove the pointer
to yourself as you go away. That's fine. Of course it means you
aren't managing the lifetimes of the objects between each other,
their lifetimes are totally dependent on external factors, but if
that's what you want, that's good.
Thanks, Kai, for pointing this out:
The good news is that GC has support for this: weak references.
Simply
declare the connection ivar as weak: __weak MyClass* connection.
GC does the
rest. No dealloc, no finalizer, no dangling pointer. And it’s even
thread
safe.
No. Under GC you don't have this problem at all. You don't need weak
references or anything else funky, it just works. MyClass1 pointing
to MyClass2 and back with ordinary object references/assign
properties does create a cycle yes, however GC can manage that
perfectly well. Once there are no references to either MyClass1 or
MyClass2 from the *ROOT* objects, even though they point to each
other, they are subject to collection. GC is able to deal with these
reference loops quite happily.
Of course you’re right, you do not need weak references under GC to
break reference count cycles - these are a non-issue under GC. I made
the implicit assumption (bad bad!) that these objects should not keep
each other alive. This is what __weak is good for: it marks a
reference which does not keep the target alive and is auto-niled when
the target dies. Depends on what you need.
And there’s no need to conditionalize __weak in any way. It’s simply
ignored under non-GC.
Best
Kai
_______________________________________________
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
_______________________________________________
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