D on next-gen consoles and for game development

[Michel Fortin]

On 2013-05-29 09:46:20 +0000, Jacob Carlborg <doob at 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.fortin at michelf.ca
http://michelf.ca/