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: Alastair Houghton <email@hidden>
- Date: Tue, 5 Feb 2008 12:40:06 +0000
On 5 Feb 2008, at 00:14, John Engelhart wrote:
I had such high hopes for Cocoa's GC system because once you're
spoiled by GC, it's hard to go back.
Unfortunately, the 4-5 months of time I've put in on Leopard's GC
system has not been nearly as pleasant. It has been outright
frustrating, and it's reached the point where I consider the system
untenable.
Honestly, this point has now been answered over and over.
I think it comes down to the fact that you have failed to appreciate
that Cocoa GC is designed for easy use with *OBJECTS*. If you're
using it with objects, it "just works".
The only problem you've been able to demonstrate is in a situation
where you are doing something that would never have worked under the
autorelease model. And you've been told that you need to add __strong
in that case, *because* the compiler won't automatically pick that
pointer out as being a pointer to GC'd memory.
All of the rest of your post is worry about nothing. You can't create
any of the problems that you claimed to be concerned about (e.g.
collections destroying temporary objects), and you had misinterpreted
the write barriers as something that they weren't (if you have the
Garbage Collection book, I don't know why you did that; it's explained
quite clearly in there).
As far as objects "not being special", they *are* special, in that the
compiler generates layout information and method signatures for them.
AFAIK the layout information (albeit in a slightly different format)
is used by the garbage collector when scanning objects, which is
another reason that you need to use __strong on instance variables if
they point to non-object garbage collected memory. FYI, the Boehm
collector can also take advantage of layout information, so you could
create the same issue with that collector too; the only reason that
you don't often see it is that programmers are generally too lazy to
specify the pointer layout of their memory blocks and just let the
collector conservatively scan everything, which, of course, is slower
and more error prone (i.e. greater likelihood of leaks).
As for your example:
- (const char *)hexString
{
char *hexPtr = NULL;
asprintf(&hexPtr, "0x%8.8x", myIvar);
return(hexPtr);
}
That method is just badly designed. You shouldn't be returning
malloc()'d memory from a method like that; at the very least you
should name the method to indicate that you're doing something funny
with memory ownership, e.g.
- (void)getHexString:(const char **)mallocedResult
{
asprintf(mallocedResult, "0x%8.8x", myIvar);
}
but better yet, why not do
- (NSString *)hexString
{
return [NSString stringWithFormat:@"0x%8.8x", myIvar];
}
or if you absolutely must return a const char * pointer,
- (const char *)hexString
{
return [[NSString stringWithFormat:@"0x%8.8x", myIvar] UTF8String];
}
which has the benefit of working exactly like -UTF8String. If you
*really* wanted, you could mess about with NSAllocateCollectable().
Kind regards,
Alastair.
--
http://alastairs-place.net
_______________________________________________
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