When releasing an object, another object belongs - xcode memory management

Is it [[MyObject itemProperty] release]

acceptable?

I currently have a MyObject that fetches some data and sets it to itemProperty. The MyObject delegate is then triggered and uses the MyObject itemProperty data and frees it. Is this an acceptable way to manage memory?

I've been told from various books that you should only free the object you are declaring. Any advice or an alternative way?

0


a source to share


3 answers


I would recommend against the approach you describe ... your instinct to ask the question about this on SO correctly as it will probably get you in trouble.

Objects are responsible for managing their own internal state, and if a delegate interferes with that internal state, it is rather unusual. A common practice for clearing memory is to have the MyObject

memory free in your method dealloc

:

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

      

In fact, if you implement dealloc

as you need to tidy up MyObject

, sending the delegate a message to release an object in itemProperty

means that the objects itemProperty

will be released twice, which will leave the ItemProperty in an unexpected state and might cause it to be released early. If you ever change your application so that other objects can use itemProperty, they find that it was mysteriously released after the delegate was called.



On the other hand, if you don't clean up memory in dealloc

, you run into a situation where you rely on the delegate call to ensure proper memory management. Can you really guarantee that the delegate method will ALWAYS be called at some point in your application? Accurately? Even if there are exceptions or other errors that could cause an unusual flow of execution for your application?

Even if you can guarantee this, as your application logic changes, it may no longer be the case, and you will forget that the delegate is performing memory management, leading to a leak or segfault. Of course, the other cocoa devs who maintain your code wouldn't think of looking at a delegate for memory management and will probably have debugging issues.

In this case, the delegate just uses itemProperty

, without saving, freeing, or autoclassing it (unless, of course, the delegate should guarantee that itemProperty will still be there after maybe MyObject disappears), When MyObject is freed, the itemProperty data will be released.

+2


a source


Usually you only let go when you highlight, new, or copy something. Since you haven't provided any code other than release yet, it's hard to tell if you should or shouldn't release.

From what you said, the best solution seems to be to use an auto-calculation pool. After receiving the data, call MyObject [itemProperty autorelease]. It will then be released automatically after your delegate has used it. However, it depends on how you do it all :-)



Again, more code will help.

0


a source


First, you are not declaring an object. Your objects create other objects, own them, pass them, etc.

Never release what you don't have. Releasing an object means "I no longer own this object." If you don't already own it, why do you refuse? Expect breakage when you make a bad mojo like this.

If you want the current owner to stop owning it, please report it. Typically, it will be something like [myObject setItemProperty:nil]

(or myObject.itemProperty = nil

). Or you can put a new object. In any case, the owner's current responsibility ceases to own it.

0


a source







All Articles