Quote:
Originally Posted by TelTikky
This might seem to be a very easy question for a lot people here ... just wondering if I have a NSMutableArray object declared like this:
NSMutableArray *overHeadObjects;
which I use to hold objects called food that I have constructed and added like this:
CCSprite * food= [CCSprite spriteWithFile:@"burger.png"
rect:CGRectMake(0, 0, 40, 40)];
[self.foodOnShelf addObject:food];
After I am done with the object, I call
[foodOnShelf removeObject:food];
Does this clean up the memory or do I still have to reclaim the memory held by the object food because the above code only remove the reference of food from the NSMutableArray but does not clean up the memory held by food itself?
|
By convention, methods return a non-owning reference to an object unless the method name includes the words copy, new, or init.
That means that you don't own the object, and don't have to release it. If you want to keep a reference to the object for later, you should retain it, or it might go away.
Container objects like arrays and dictionaries send a retain message to objects that you add to them. Containers also send a release message to objects when you remove them from the container.
Putting all that together:
The CCSprite method spriteWithFile
should return a non-owning reference to a CCSprite object, since the method name does not include the words new, copy, or init. (Rare exceptions to this rule should be well documented.) The CCSprite class is a non-Apple class (part of Cocos2D, correct?) I'd double-check that that method follows the rules and returns a non-owning reference. Third party codes doesn't always follow the rules.
Adding "food" to the array causes the array to retain food. (Kind of like my waistline retains food.)
Removing "food" from the array causes the array to release the food. (unlike my waist...)
So you don't need to do anything else. Your array is retaining your food when you add it, and releasing it when you remove it from the array.
Edit: You should search the XCode docs for the chapter called "Memory Management Programming Guide", and read the first several sections. The bit at the end about autorelease pools might be confusing at first. The first three sections cover the most important stuff. If you only read one part, read the subsection "Basic Memory Management Rules". Read that part over and over until you memorize it. It is perhaps the most important thing to get right about Cocoa programming:
Quote:
Basic Memory Management Rules
The memory management model is based on object ownership. Any object may have one or more owners. As long as an object has at least one owner, it continues to exist. If an object has no owners, the runtime system destroys it automatically. To make sure it is clear when you own an object and when you do not, Cocoa sets the following policy:
You own any object you create
You create an object using a method whose name begins with “alloc”, “new”, “copy”, or “mutableCopy” (for example, alloc, newObject, or mutableCopy).
You can take ownership of an object using retain
A received object is normally guaranteed to remain valid within the method it was received in, and that method may also safely return the object to its invoker. You use retain in two situations: (1) In the implementation of an accessor method or an init method, to take ownership of an object you want to store as a property value; and (2) To prevent an object from being invalidated as a side-effect of some other operation (as explained in “Avoid Causing Deallocation of Objects You’re Using”).
When you no longer need it, you must relinquish ownership of an object you own
You relinquish ownership of an object by sending it a release message or an autorelease message. In Cocoa terminology, relinquishing ownership of an object is therefore typically referred to as “releasing” an object.
You must not relinquish ownership of an object you do not own
This is just corollary of the previous policy rules, stated explicitly.
|
NSMutableArray memory management
Linear Mode
