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.
_______________________________________________
Cocoa-dev mailing list ([email protected])
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [email protected]
