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: Wade Tregaskis <email@hidden>
- Date: Mon, 4 Feb 2008 18:33:05 -0800
Then take a look again at the method prototype:
- (const char *)UTF8String; // Convenience to return null-
terminated UTF8 representation
Can you clearly and concisely articulate why the pointer returned
from
this particular method requires a __strong qualifier?
Yes. You're trying to store the pointer somewhere besides a root.
- (const char *)hexString
{
char *hexPtr = NULL;
asprintf(&hexPtr, "0x%8.8x", myIvar);
return(hexPtr);
}
Now what?
asprintf() is documented to place a result in hexPtr that requires
you call free() upon it. Your code needs to do that regardless of
whether you adopt retain/release or GC. The documentation discusses
how GC replaces the retain/release/dealloc/autorelease reference
counting. You should not infer that it also replaces free() or
other memory models found on the system like Carbon or C++.
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.
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.
It would seem to me that, in order to completely expose these
semantics, voodoo methods such as this would need to define their
return value as something like "autoreleased const char*". That way
you have the extra semantics of knowing that the returned pointer is
autoreleased/GC'd, and the compiler could even issue a warning if you
try to assign it to a non-strong variable. [[ bonus points to the gcc
guys if they can get the compiler to warn you that you're using an
autoreleased variable beyond a pool flush, without retaining it
first... I hate those kinds of errors ]]
Wade
_______________________________________________
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