3 ms·

On the other hand, I'm rather surprised that Gruber is looking to defend reference counting I suspect that you're not up to speed on some things that were reve

by pohl 15y ago

On the other hand, I'm rather surprised that Gruber is looking to defend reference counting I suspect that you're not up to speed on some things that were revealed at WWDC this year, because "reference counting" and "automated reference counting" are not the same things. The latter is in the spirit of the last few paragraphs by Linus Torvalds in his famous 2002 discussion of Garbage Collection, when he says Does it take more effort? Yes. The advantage of GC is that it is automatic. But CG apologists should just admit that it causes bad problems and often _encourages_ people to write code that performs badly. I really think it's the mindset that is the biggest problem. A GC system with explicitly visible reference counts (and immediate freeing) with language support to make it easier to get the refcounts right (things like automatically incrementing the refcounts when passing the object off to others) wouldn't necessarily be painful to use, and would clearly offer all the advantages of just doing it all by hand. http://news.ycombinator.com/item?id=2473932 http://news.ycombinator.com/item?id=2473932 ...except ARC is better than Linus was imagining in the above, because it manages to do it without the "explicitly visible" part. http://clang.llvm.org/docs/AutomaticReferenceCounting.html http://clang.llvm.org/docs/AutomaticReferenceCounting.html Since you're a Siracusa fan... http://arstechnica.com/apple/reviews/2011/07/mac-os-x-10-7.ars/11 http://arstechnica.com/apple/reviews/2011/07/mac-os-x-10-7.a...

smikhanov 15y ago
except ARC is better than Linus was imagining in the above, because it manages to do it without the "explicitly visible" part I haven't read the article you're linking, but how does ARC manage to keep this invisible? The usual trouble is supporting legacy code. Even with C++/Boost, where there's a variety of _ptr templates each promising either automatic deletion or automatic reference count decrement at an appropriate time, you can find yourself in a situation where there's a legacy C function accepting and returning, say, wchar_t*. You simply cannnot avoid doing malloc/free or retain/release in this situation.
- pohl 15y ago
  ARC handles this by being something you can choose in a per-compilation-unit basis, and by providing functions/macros for working with these legacy libraries. You still have to say what to do at such boundaries.

by pohl 15y ago

smikhanov 15y ago

except ARC is better than Linus was imagining in the above, because it manages to do it without the "explicitly visible" part I haven't read the article you're linking, but how does ARC manage to keep this invisible? The usual trouble is supporting legacy code. Even with C++/Boost, where there's a variety of _ptr templates each promising either automatic deletion or automatic reference count decrement at an appropriate time, you can find yourself in a situation where there's a legacy C function accepting and returning, say, wchar_t*. You simply cannnot avoid doing malloc/free or retain/release in this situation.

pohl 15y ago
ARC handles this by being something you can choose in a per-compilation-unit basis, and by providing functions/macros for working with these legacy libraries. You still have to say what to do at such boundaries.