3 ms·
Sorry, but that's nonsense. Cycles don't just magically appear, you write them. So writing refcounting code simply means being aware of this when designing the
by vsl 11y ago
Sorry, but that's nonsense. Cycles don't just magically appear, you write them.
So writing refcounting code simply means being aware of this when designing the more complicated data structures in your code to use weak backreferences.
File objects are not secretly stashed in complicated graphs to prevent their destruction and you very much can rely on their behavior. GC passes to clean up cycles is something you got confused about: that's what GC does (because unrooted cycles are very much an issue there too!), not refcounting where you always have to break the cycles yourself, manually, preferably when designing the data structures.
- bjourne 11y ago> Cycles don't just magically appear, you write them. That's like saying memory leaks doesn't magically appear, you write them. In real code, ref cycles are everywhere and it is not trivial to know beforehand what code will generate cycles. And don't give the spiel about how that's only something that affects bad programmers.
- comex 11y agoAll modern Objective-C codebases and a high percentage of large C++ codebases use refcounting without a cycle collector. Some of them have memory leaks, and there are some quite ugly cases like [1], but most of them have it under control. So it's not like relying on pure refcounting is impractical in the real world; it's just a bit more difficult to deal with than full GC. [1] http://albertodebortoli.github.io/blog/2013/08/03/objective-c-blocks-caveat http://albertodebortoli.github.io/blog/2013/08/03/objective-...