Memory management with archives
Memory management with archives
- Subject: Memory management with archives
- From: Will Mason <email@hidden>
- Date: Sun, 20 Feb 2005 02:05:28 -0800 (PST)
- Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
I'm writing a subclass of NSCoder, as I'm writing a streaming subsystem
for my framework (http://sourceforge.net/projects/objectivelib/), so I
need to be able to reliably deal with the expectations of existing
Cocoa/GNUstep objects, like NSNumber, in terms of how they archive
themselves. A problem that I've recently encountered is the memory
management when [NSCoder decodeValueOfObjCType:at:] is called. I cannot
find any explanation in the Apple docs about memory management of
non-object pointers expect for the following:
You cant encode a pointer and get back something useful at decode
time.
Lacking anything useful from Apple about Cocoa, I originally modeled my
code on the memory management model used by GNUstep, as that was the
only one to which I had source code. In GNUstep all decoded pointers
are autoreleased. My unit tests reveal that Cocoa does not operate
under that assumption, as autoreleasing the returned pointers results
in multiple free's of the same pointer.
In spite of the documentation's obvious disdain for decoding pointers,
NSNumber decodes a char* indicating the type of data that it holds
every time initWithCoder: is called. It appears that the newly
initialized NSNumber also expects to own the pointer which is returned
to it, thus preventing the optimization of sharing references to the
same pointer between different objects.
I've been left to infer this on my own, as I have found nothing in
Apple's documentation that tells me what the memory management
assumptions with non-object pointers are in Cocoa, aside from the
admonition not to use them (even though Cocoa makes no effort to heed
that warning itself). As far as I can tell, the only memory management
questions that are addressed in Apple's documentation are for object
references. If anyone can tell me what an idiot I have been for
overlooking something, please tell me. I'm quite used to being an
idiot.
Thank you for any help,
Will
_______________________________________________
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