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. 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. I guess I should tell you more about the model so you would get the picture. I am modeling a network of physical processes, look at the representation: http://i729.photobucket.com/albums/ww297/karolisr/example.png As you can see each box has one or more little "inputs" and "outputs" in fact these inputs and outputs are instances of one class (KROMPort). When I drag a connection from output to an input, I set each "port's" connection property to point to another "port". So Input points to Output and Output points to Input. Only one-to-one relationships are allowed (one connection per input/output). Essentially this is what I have: KROMPort * input; KROMPort * output; output.connection = input; input.connection = output; 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; SELF here is either an input or an output. 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. I never programmed for GC, so I should check then if GC is enabled in my @interface and create a separate declaration looking like this then?: "__weak KROMPort * connection" Thanks all! _______________________________________________ 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]
