3 ms·

ARC is reference counting in only the most literal sense; the compiler assumes all responsibility for managing reference increments/decrements and ensuring thin

ARC is reference counting in only the most literal sense; the compiler assumes all responsibility for managing reference increments/decrements and ensuring things are destroyed as soon as they are no longer referenced. It's garbage collection without any of the nasty downsides. And Siracusa has been trotting out his pet theory about Objective-C/Cocoa being a dead end for years now. All of the articles he's written on the subject have made it clear that a) he has essentially no experience with the subject he is trying to discuss, and b) he's really, really bad at predicting the future of Apple's development landscape. Since his first article calling Objective-C/Cocoa a dying platform, we've witnessed the introduction of an entirely new platform based on them (iOS), an enormous surge in usage and demand for Objective-C talent, and massive overhauls in the language (Objective-C 2.0) and memory model (first a conservative garbage collector, and now ARC). Siracusa has been out to lunch on the subject for years.

chc 15y ago
It's also garbage collection without many of the upsides — for example, normal garbage collection supports concurrency better than reference counting does, and circular references trip up ARC but not a proper garbage collector.
- strmpnk 15y ago
  I don't see how the concurrency claim makes any sense. Many concurrency primitives revolve around counts (for example, a semaphore). Likewise, GC may be able to deal with messy situations (ones that I'd advise you avoid anyway), but brings problems too like non-deterministic lifetimes. ARC isn't a silver bullet but I think it gets pretty close to how people use GC in day to day software.
  - chc 15y ago
    With reference counting, each strong assignment has to alter at least one object's reference count in a thread-safe manner. With garbage collection, you can just assign — a fast, atomic operation. Also, one of those "messy situations" that you'd advise us to avoid is the nigh-ubiquitous Cocoa controller-delegate pattern. That's a circular reference. With ARC, you have to explicitly break it. It's not a big darn in general, but it's a definite weakness of retain counting. My point is that it's a massive hyperbole to call ARC "garbage collection without any of the nasty downsides."
    - strmpnk 15y ago
      Reference counting has plenty of instruction specific atomic operations on common processors in use today (and no, GC routines need write barriers in most cases that atomic counting is needed). But you're right, it's tricky, but that's why it's important to make all of that automatic and transparent to the programmer. Delegation patterns are complex for lifetime management though that is why they have spent a good portion of their documentation on helping people understand when to use zeroing weak references which is a very easy fix for problems like this. Their heuristics work better than I imagined here. Still trickier than GC but much more consistent. So far the downsides are pretty small relative to manual memory management and close to GC without trading off the consistency of manual memory management. I'd say "garbage collection without any of the nasty downsides" is more accurate in this case than not.

chc 15y ago

It's also garbage collection without many of the upsides — for example, normal garbage collection supports concurrency better than reference counting does, and circular references trip up ARC but not a proper garbage collector.

strmpnk 15y ago
I don't see how the concurrency claim makes any sense. Many concurrency primitives revolve around counts (for example, a semaphore). Likewise, GC may be able to deal with messy situations (ones that I'd advise you avoid anyway), but brings problems too like non-deterministic lifetimes. ARC isn't a silver bullet but I think it gets pretty close to how people use GC in day to day software.
- chc 15y ago
  With reference counting, each strong assignment has to alter at least one object's reference count in a thread-safe manner. With garbage collection, you can just assign — a fast, atomic operation. Also, one of those "messy situations" that you'd advise us to avoid is the nigh-ubiquitous Cocoa controller-delegate pattern. That's a circular reference. With ARC, you have to explicitly break it. It's not a big darn in general, but it's a definite weakness of retain counting. My point is that it's a massive hyperbole to call ARC "garbage collection without any of the nasty downsides."
  - strmpnk 15y ago
    Reference counting has plenty of instruction specific atomic operations on common processors in use today (and no, GC routines need write barriers in most cases that atomic counting is needed). But you're right, it's tricky, but that's why it's important to make all of that automatic and transparent to the programmer. Delegation patterns are complex for lifetime management though that is why they have spent a good portion of their documentation on helping people understand when to use zeroing weak references which is a very easy fix for problems like this. Their heuristics work better than I imagined here. Still trickier than GC but much more consistent. So far the downsides are pretty small relative to manual memory management and close to GC without trading off the consistency of manual memory management. I'd say "garbage collection without any of the nasty downsides" is more accurate in this case than not.