On 2013-05-29 09:46:20 +0000, Jacob Carlborg <d...@me.com> said:
On 2013-05-29 09:05, Paulo Pinto wrote:
The main reason was that the GC never worked properly given the C
underpinnings of Objective-C.
Too many libraries failed to work properly with GC enabled, plus you
needed to fill your code with GC friendly annotations.
So I imagine Apple tried to find a compromises that would work better in
a language with C "safety".
Even that is only supported at the Objective-C language level and it
requires both compiler support and that objects inherit from NSObject as
top most class, as far as I am aware.
Anyway it is way better than pure manual memory management.
I'm pretty it works for their CoreFoundation framework which is a C
library. NSObject, NSString and other classes are built on top of
CoreFoundation.
It does for CF types which are toll-free bridged, if you mark them to
be GC managed while casting.
http://developer.apple.com/library/ios/#documentation/CoreFoundation/Conceptual/CFDesignConcepts/Articles/tollFreeBridgedTypes.html
For
instance, CFString and NSString are just different APIs for the same
underlying object, so you can cast between them. But CoreFoundation
itself won't use the GC if you don't involve Objective-C APIs. The
interesting thing is that objects managed by the now deprecated
Objective-C GC also have a reference count, and won't be candidate for
garbage collection until the reference count reaches zero. You can use
CFRetain/CFRelease on GC-managed Objective-C objects if you want, it's
not a noop.
--
Michel Fortin
michel.for...@michelf.ca
http://michelf.ca/
