On 14/01/2011, at 5:58 PM, John Bartleson wrote: > I'm glad to see this, because it's really the answer to my original question. > Poking around a little, one finds > NSInvocation's retainArguments method, which is probably what NSUndoManager > uses. > > You've stated that I "only need to follow the rules." This left me to wonder > which memory management rules > I had missed that would predict the above result. My day-to-day MM rules > include the ususal: "If you create it > (alloc, new, copy, etc.) you own it," "You can take ownership with retain," > "When you're finished with something > you own, you must release it," etc. > > In addition we also learn special MM rules for useful framework classes, e.g. > a collection will retain objects > passed to it. I don't, however, know any special rules pertaining to > NSUndoManager and NSInvocation. So I re-read > Apple's "Memory Management Programming Guide." I honestly can't find anything > in there that would be an obvious > rule pertaining to the current topic. Which rules are relevant here? >
The standard rules. There are no special rules pertaining to NSUndoManager and NSInvocation (though with invocations, there are certain cases where not retaining the arguments might be apropos, which is why there is a -retainArguments method on NSInvocation - NSInvocations are used in places other than undo). I wouldn't say that "e.g. a collection will retain objects passed to it" is a special rule. It necessarily follows that since collections own their contents, they will retain them. Most objects that store objects either singly or multiply use collection classes internally to do so, so in general whenever any object is passed to another, and is expected to live longer than a moment more, it will be retained. However, I think you're focusing too much on what (framework) objects do with objects you pass them from 'outside' - actually, it doesn't matter. Those objects will do as they see fit with respect to object ownership, according to the rules. You need only focus on what your code does, to see that it follows the rules. e.g., take this hypothetical set up for undo, based on your code: NSArray* descriptorsCopy = [[myTableView descriptors] copy]; // you now own 'descriptorsCopy' [[myUndoManager prepareWithInvocationTarget:self] sortWithDescriptors:descriptorsCopy]; // you still own 'descriptorsCopy'. Does the undo manager? Who knows nor cares? // do you have any further use for the descriptorsCopy? No, so you're done with it. It's now your responsibility to release it as you no longer own it [descriptorsCopy release]; In the middle step, why should YOU worry about whether the undo manager has retained 'descriptorsCopy'? It's not your responsibility how that object works. It might have retained the object, copied it, turned it into something completely different, or buried it in soft peat for three months. Not your concern. All you know is, following that line, you have no further interest in the object, so you release it. It's when you try to second-guess the behaviour of other objects where you will run into trouble. In other words, if you attempt to compensate for a release or retain elsewhere in your code (or even worse, in code you're using that isn't yours, like a framework class). That's not following the rules. In such a case, the code analyser will flag a potential memory management error. That's a great tool for learning how to write correct code in this respect. > You mentioned memory tracing tools. I'm familiar with Instruments, but I > wasn't aware you could use it > to trace individual variables. Did you have a particular tool in mind? I believe the 'allocation' tool can do this, though I rarely use it so my memory may be faulty. Or it might be the 'leaks' tool. --Graham _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com
