Re: primitiveValueForKey Memory Management
Re: primitiveValueForKey Memory Management
- Subject: Re: primitiveValueForKey Memory Management
- From: mmalcolm crawford <email@hidden>
- Date: Sun, 29 May 2005 12:59:56 -0700
On May 29, 2005, at 6:22 AM, email@hidden wrote:
The thought does occur though that willAccessValueForKey: may alloc
memory, and didAccessValueForKey: will release it... I doubt it,
but just in case, you should probably do a [tmpValue retain] before
you call didAccessValueForKey:, and then return [tmpValue
autorelease]. Again though, this would indicate a design flaw in
CoreData (or whatever these primitive key methods are), in my mind
- it should be returning an autoreleased value, to avoid any such
concerns in a procedural method.
This is unhelpful. The documentation makes clear what the {will,did}
AccessValue methods do. They do not relate to memory management per
se, and there is no reason to think that they might malloc and
release memory in an arbitrary way.
The documentation is explicit about the role of the primitive accessors:
"NSManagedObject’s implementation of the primitive accessor methods
handle memory management for you."
The documentation also provides several complete examples of how to
write custom accessor methods for managed objects. If you follow
these patterns, then your managed object class will adhere to the
memory management rules for Cocoa.
<http://developer.apple.com/documentation/Cocoa/Reference/
CoreData_ObjC/Classes/NSManagedObject.html>
I'm not familiar with CoreData, but in terms of general ObjC memory
management, you should technically be returning [[tmpValue retain]
autorelease] (which is also what primitiveValueForKey should be
returning anyway).
It is not true that "you should technically be returning [[tmpValue
retain] autorelease]". This pattern may help to make your code
thread safer or more robust against edge cases in memory management
(see <http://www.stepwise.com/Articles/Technical/2002-06-11.01.html/
>, "Defensive programming"), however it has performance
implications, and alternatives are not only acceptable, they are also
generally more common: <http://developer.apple.com/documentation/
Cocoa/Conceptual/MemoryMgmt/Concepts/ObjectOwnership.html>.
mmalc
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden