Re: GC pros and cons
Re: GC pros and cons
- Subject: Re: GC pros and cons
- From: Hamish Allan <email@hidden>
- Date: Tue, 30 Jun 2009 23:11:55 +0100
On Tue, Jun 30, 2009 at 10:03 AM, Philip Aker<email@hidden> wrote:
> Just to be clear, Hamish wrote:
>
>> Compilers conforming to C99 I would trust.
>> gcc -fobjc-gc... not so much.
>
> Meaning to me that C99 is a direct descendent of C89 and K&R before that. So
> that means roughly 30 years of evolvement and nit-picking high and low by a
> lot of people on nearly all platforms extant. Objective-C 2.0 doesn't seem
> to have a published standard (like with a language syntax summary as in
> Appendix A of C99). Apple has a track record of introducing stuff that is
> subsequently dumped. And gosh, I might not like to be the one who trusted in
> GC to be around forever and then found out I had to account for all those
> [[NSThing alloc] initWithImpunity:…] calls in Mac OS X 10.7.
Just to be clear, my concern is not that Apple might dump GC in a
future release. what I wrote was in reply to Andy's seeming reductio:
"if you take this to the extreme you'd insist on programming in
assembly because you don't trust compilers to properly put things on
the stack on entering a function and remove them on exiting"
because this trust in automatic storage duration is *precisely* what
is lacking with the current implementation of GC in Objective-C.
What really concerns me is that several Apple engineers participating
in the thread I linked to are in complete denial about the way in
which gcc -fobjc-gc breaks C99 (the closest I got to an admission was
Greg Parker saying "The underlying problem is that the garbage
collector is not in fact a conforming program, so following C99's
rules may not do what GC wants.")
Like I said, I understand *why* it breaks C99, and I think the
breakage is worthwhile, but it really ought to be properly documented.
Changing NSData to return collectable memory won't fix the problem.
Hamish
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden