4 ms·
I very strongly disagree. ARC still reveals the underlying nuts and bolts, necessitating a basic understanding of reference counting systems. It doesn't solve
by nupark2 15y ago
I very strongly disagree. ARC still reveals the underlying nuts and bolts, necessitating a basic understanding of reference counting systems.
It doesn't solve retain cycles, thus requiring the judicious use of __weak in cases where a retain cycle may emerge. Determining where such a cycle may occur requires understanding reference counting. This significantly impacts your expression of algorithms where the simplest/best implementation may involve cyclic object graphs.
Additionally, ARC does not handle mixing CoreFoundation and Foundation code directly, requiring one to manually express bridging rules based on an understanding of reference counting.
It may be that ARC gradually smooths out its rough edges, and we find ourselves in a situation similar to GC, where developers need only understand the difference between weak and strong references, and the opportunities that exist there for leaks caused by maintaining strong live references.
However, we're still a bit far from that point, and newcomers should remain well-aware of retain/release and the vagaries of reference counting systems.
- rpwilcox 15y agoI agree (with you, nupark) For example, thr other day I was debugging a crash in my Cocoa (ARC) app. I've been programming Cocoa since 10.1, although I stepped away for a few years. Anyway, random crash. My "manage memory manually" training knew it was an object getting released too early: I know I needed to retain it. Think think think... Of yes, my @property declaration was missing a retain declaration. Of course cocoa was releasing that object! ARC sure helps, and between it and use of the autorelease pool (thanks Brent Simmons!) I hardly have to worry about memory management at all - except when I do, then I need to know what ARC is or is not doing behind the scenes.