On Friday, 12 September 2014 at 12:39:51 UTC, Paulo Pinto wrote:
On Friday, 12 September 2014 at 07:46:03 UTC, eles wrote:
On Thursday, 11 September 2014 at 19:56:17 UTC, Paulo Pinto
wrote:
Am 11.09.2014 20:32, schrieb Daniel Alves:
It is incredible how Objective-C's ARC became a symbol for
reference counting, instead of the living proof of Apple's
failure to produce
a working GC for Objective-C that didn't crash every couple
of seconds.
I think I fail to grasp something here. For me, ARC is
something that is managed at runtime: you have a counter on a
chunk of memory and you increase it with each new reference
towards that memory, then you decrement it when memory is
released. In the end, when the counter reaches 0, you drop the
chunk.
OTOH, code analysis and automatically inserting free/delete
where the programmers would/should have done it is not really
that. Is a compile-time approach and not different of manual
memory management.
Which one is, in the end, the approach took by Apple, and
which one is the "true" ARC?...
ARC was a term popularized by Apple when they introduced the
said feature in Objective-C.
In the GC literature it is plain reference counting.
ARC in Objective-C is a mix of both approaches that you mention.
It only applies to Objective-C classes that follow the
retain/release patterns since the NeXTStep days. For structs,
malloc() or even classes that don't follow the Cooca patterns,
only manual memory management is possible.
The compiler inserts the retain/release calls that a programmer
would write manually, at the locations one would expect from
the said patterns.
Then a second pass, via dataflow analysis, removes the pairs of
retain/release that are superfluous, due to object lifetime
inside a method/function block.
This way you get automatic reference counting, as long as those
classes use the said patterns correctly. As a plus the code
gets to interact with libraries that are clueless about ARC.
Now, having said this, when Apple introduced GC in Objective-C
it was very fragile, only worked with Objective-C classes, was
full of "take care of X when you do Y" and required all
Frameworks on the project to have compatible build settings.
Of course, more often than not, the result was random crashes
when using third party libraries, that Apple never sorted out.
So ARC in Objective-C ended up being a better solution, due to
interoperability issues, and not just because RC is better than
GC.
--
Paulo
[Caveat: I'm no expert]
I once read a manual that explained the GC in Objective-C (years
ago). It said that some objects never get collected although
they're dead, but the garbage collector can no longer reach them.
But maybe that's true of other GC implementations too (Java?).
ARC definitely makes more sense for Objective-C than what they
had before. But that's for Objective-C with its retain-release
mechanism. Also, I wonder, is ARC really "automatic". Sure, the
compiler inserts retain-release automatically (what the
programmer would have done manually in the "old days"). But
that's not really a GC algorithm that scans and collects during
runtime. Isn't it cheating? Also, does anyone know what problems
Apple programmers have encountered with ARC?
