Re: Use of Mac OS X 10.5 / Leopards Garbage Collection Considered Harmful
Re: Use of Mac OS X 10.5 / Leopards Garbage Collection Considered Harmful
- Subject: Re: Use of Mac OS X 10.5 / Leopards Garbage Collection Considered Harmful
- From: Quincey Morris <email@hidden>
- Date: Mon, 4 Feb 2008 20:28:10 -0800
On Feb 4, 2008, at 18:33, Wade Tregaskis wrote:
I believe Mr. Engelhart is trying to express the ambiguity of
current C-typed methods, such as UTF8String, which don't clearly -
in C/ObjC - indicate their memory management scheme. As noted,
NSString's UTF8String returns autoreleased/GC'd memory, while
hexString (above) returns malloc'd memory. But their return values
are typed identically. This is still something you need to think
about with non-GC, though, because you'd need to know whether you
must explicitly free() the returned value or not. Thus why this is
documented for that method.
The ambiguity isn't in the method.
The pedigree of an (id) variable's pointer is known: it was allocated
from the pool of object memory. For an attibuteless (void*) variable's
pointer, there's nothing syntactic or semantic that tells you whether
it points to dynamically allocated memory or statically allocated
stack memory or anything else that's got an address. Trying to pin the
blame for this on Apple seems naive. A (void*) in C is dumb as dirt,
by design.
So with regard to memory allocation, (id) is perfectly unambiguous
while (void*) is horribly ambiguous. The OP's proposed solution for
resolving the ambiguity -- unconditionally assuming that (void*)
refers to allocated object memory and guessing at the truth at garbage
collection time -- has a performance price that Apple wasn't prepared
to make us developers pay.
The *most* that the -[NSString UTF8String] example proves is that
Apple made a poor API design choice for that method. (And it was lousy
before GC ever came along. If it returned a NSData object I doubt we'd
be having this discussion.) But at least the danger was documented.
I think the core of the issue is that any method that returns
pointers is potentially doing magic behind your back, relying on
autorelease/GC, which previously you didn't really need to care
about quite the same; the returned string was seemingly always valid
(and maybe you leaked, at worst). This works okay with autorelease,
because the points at which autorelease pools are flushed are well
defined and more or less controllable. However, with GC you now
have the potential for collection at any time, so - although it may
be rare - it's possible for old code, that relied on those
particular autorelease semantics, to break.
What magic? The internals of a method are hidden by design, not by
magic, and won't bite anyone unless there's an internal bug. The
return values in all the cases discussed so far are 100% deterministic
and 100% voodoo-free, although you might have to read the
documentation to find out the answer. That might be more work, but
it's hardly magical.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden