On Thursday, 11 July 2013 at 07:34:48 UTC, Jacob Carlborg wrote:
On 2013-07-10 20:43, Paulo Pinto wrote:

What sometimes goes missed between the lines is that one of the
decisions to go ARC instead of GC, is because the Objective-C GC never worked properly and ARC offers a better fit for the current state of
Objective-C world.

First of all, GC was an opt-in and very few libraries supported it.

Wasn't it possible to use the GC with all libraries but not the other way around?

No, it depended how you compiled the code.

https://developer.apple.com/legacy/library/#documentation/Cocoa/Conceptual/GarbageCollection/Articles/gcEssentials.html#//apple_ref/doc/uid/TP40002452-SW1

Using -fobjc-gc-only meant your library could only work with GC enabled applications.

Or another quote from the documentation:

"Not all frameworks and technologies support garbage collection; for example, iCloud is not supported in applications that use garbage collection."



Then we have the typical issues with a conservative GC in a C based language, which lead to tons of issues if one looks into developer forums.

The GC only worked for the Objective-C part.

True, but you were forced to do manual hacks like calling objc_assign_global() for write barriers in global and static variables.

There is the compiler flag -Wassign-intercept to show where write barriers are being generated as a help method if everything is being generated properly.

The Core Foundation needs to be used in a slight different way when interacting with GC enabled objects.

With ARC all these problems do not exist, because the compiler does what the developers would be expected to do manually anyway.

This is way there was such a joy when ARC was announced, not because GC per se is bad.

--
Paulo

Reply via email to