On releasing object belong to another object - xcode memory management

Question

Is [[MyObject itemProperty] release] acceptable?

Currently, I have MyObject fetching some data and sets it to itemProperty. The delegate of MyObject then fires off and uses MyObject's itemProperty data and releases it. Is this an acceptable way of memory management?

I've been told from various books that you should only release an object you declare. Any tips or alternative way?

Answer 1

Generally you release only when you alloc, new or copy something. Since you have not provided any other code besides releasing, it’s hard to say whether you should or should not release.

From what you said, the best solution seems to be using autorelease pool. After fetching your data, make MyObject call [itemProperty autorelease]. Then it will be released automatically after your delegate has used it. However it depends on how you do it all :-)

Again, more code will help.

Answer 2

I'd recommend against the approach you're describing... your instinct to ask a question about it on SO is correct as this probably going to lead to trouble.

Objects are responsible for managing their own internal state, and having a delegate interfere with that internal state in this way is quite unusual. The normal practice for cleaning up memory is to have to have MyObject release memory in its dealloc method:

- (void)dealloc {
    [item release];
    [super dealloc];
}

In fact, if you are implementing dealloc as you should to tidy up MyObject, having the delegate send a release message to the object at itemProperty will mean that the itemProperty objects gets released twice, which will leave itemProperty's retain count in an unexpected state and may cause it to be deallocated early. If you ever change the app so that other objects may be using itemProperty, they will find it's been mysteriously deallocated after the delegate is called.

On the other hand, if you don't tidy up memory in dealloc, you run into a situation where you are relying on having the delegate being called to ensure that memory is properly managed. Can you really guarantee that the delegate method will ALWAYS be called at some point in your app? Without fail? Even if there are exceptions or other error conditions that may cause an unusual execution flow for your application?

Even if you can guarantee this, as the app logic changes, this may no longer be the case and you'll forget that the delegate is doing the memory management, leading to a leak or a segfault. Certainly, other cocoa developers maintaining your code would not think to look at the delegate for memory management and would probably have a hard time debugging issues that arise.

In this case, have the delegate just use the itemProperty without retaining, releasing, or autoreleasing it (unless, of course, the delegate needs to guarantee that the itemProperty will still be around after, perhaps, MyObject is gone). When MyObject is deallocated, the itemProperty data will be released then.

Answer 3

First, you don't declare an object. Your objects create other objects, own them, pass them around, etc.

Never release something you don't own. Releasing an object means “I wish to no longer own this object”. If you already don't own it, what are you relinquishing? Expect breakage when you do bad mojo like this.

If you want the current owner to stop owning it, tell it to. Generally, this will be something like [myObject setItemProperty:nil] (or myObject.itemProperty = nil). Or you could supply a new object. Either way, it's the current owner's responsibility to stop owning it.