On Mar 14, 2009, at 3:29 AM, Paul Sanders wrote:
I'm sorry Bill, but the more I hear about GC and in particular the
difficulties of using it with malloc'd memory the gladder I am not
to be
using it. I guess that one should not be surprised that it is
difficult to
retro-fit it in the way that you are forced to. Caveat emptor!
Heh. No need to apologize. Seriously -- no need -- do whatever you
need to do to serve your customer's needs as efficiently as you can!
I simply fail to understand the difficulty of using GC. with malloc'd
memory. Malloc'd memory works *exactly* as it always has.
Instead of calling free() in -dealloc, you call it in -finalize.
As for storing object references into malloc()'d memory, you need to
CFRetain()/CFRelease() on the way in/out. Same as always, but a
function call -- that will work in non-GC -- vs. a method call.
As for interior pointers; interior pointers are equally as
problematic under GC vs. non-GC. Under GC, they tend to blow up a
little bit sooner, but only in situations where the non-GC pattern was
-- at the very least -- fragile to start with.
Given all of that combined with the overall boost in programmer
productivity at the higher level and the decreased number of crashes
in the application, especially plug-in driven applications, I --
personally -- will never waste my customer's time writing non-GC'd
Cocoa code again, given the choice (and, to be utterly clear, there
are a number of non-technical reasons to stick with non-GC -- iPhone,
being the 800 lbs gorilla in the room).
Furthermore, by embracing GC, my applications will be faster and even
easier to debug as the underlying collector is improved. For those of
you who paid attention to the speed of GC under Leopard, there was a
many times performance improvement between it being first turned on
and what was finally released.
Obviously, I can't speak to Snow Leopard performance beyond saying
that there has been significant effort on this front.
GC is similar to Core Data. If you had a Core Data app on Tiger,
there were numerous operations on Leopard that were significantly
faster -- many, many times faster -- that you got for free.
But, heck, if you think it will serve your product's time to market
better by focusing on the innards than the directly customer facing
bits and then playing catch-up when Apple significantly advances the
state of the art of similar technologies, well... bully for you!
(Yah -- snarky -- I know -- but, seriously, if every engineering
decision is not made in the "how does this best serve my target
users?", then you are likely asking and answering the wrong question...)
b.bum
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
