Graham: thanks for your comment and thanks for being patient with a
relative n00b. Hopefully we can
nail this topic down in a post or two.
You are not required to verify it. (Though you may do so using the
memory tracing tools). You only need to follow the rules, and
understand that the undo manager also follows the rules. When
everyone follows the rules, the need to verify and check ownership
disappears - you can take it as read that correct memory management
is performed. In other words you only need to concentrate on
ensuring YOUR code follows the rules - the frameworks can be assumed
to.
I'm sure you'd agree that when we're learning a new environment,
references and documentation are only
part of the process. If we can't figure out the docs, and lacking an
expert in the next cubicle to ask,
then writing a test app will usually quickly answer our question. This
is where a legitimate need to
verify and check object ownership comes from.
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?
So yes, that means that the undo manager does take ownership of the
arguments, because it owns the invocations.
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?
_______________________________________________
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
