On Tue, Feb 04, 2014 at 01:11:23PM +1000, Manu wrote: > On 4 February 2014 12:05, Nick Sabalausky < > [email protected]> wrote: > > > On 2/3/2014 4:13 PM, H. S. Teoh wrote: > > > >> I've seen real-life examples of ARCs gone horribly, horribly wrong, > >> whereas had a GC been used in the first place things wouldn't have > >> gone down that route. > >> > >> > > I'm curious to hear more about this. > > > > Me too.
Well, first I have to apologize for my misleading message, I meant *reference counting systems*, not ARC specifically, since the case I had in mind is a reference-counting system implemented in C, so obviously it's not *A*RC. :-( But anyway, what happened is that in the past, we used to do just straight malloc/free, but over time discovered that it was an unending source of embarrassing pointer bugs and memory leaks. So at some point, the team lead decided to implement a reference-counting system instead. Which worked *better*, I suppose, but it was hardly the panacea that people might think. It was still prone to pointer bugs and memory leaks caused by not updating the reference counts properly -- something that an ARC wouldn't have, I guess. But then people started doing things with dtors that they shouldn't do... like this one especially egregious abuse that I had in mind, where there was a container pointing to a bunch of subobjects, and whenever one of the subobjects got deleted, the rest must be deleted as well. This was implemented by having the dtor of the subobject destruct the container, which, according to refcount thinking, should "automatically" clean up everything. Except that it didn't, because this implementation was wrong on so many levels... the first being that the subobject can't have its dtor invoked unless the container didn't contribute to the reference count, and of course, once the dtor is invoked, it tries to destruct the container by decreasing *its* reference count, which makes one wonder who's keeping the reference to the container, and what happens with the container's reference to the current subobject. This was the case that really needed a GC, because there are just too many cross-references going on. Had we used a GC to begin with, we'd never have gone down this slide of increasingly wrong code. And this was just the one instance we discovered; who knows how many other such abuses are still lurking in the code somewhere. Now you may argue that an ARC wouldn't permit this sort of abuses, but the fact of the matter is, the same people who can't write bug-free malloc/free code are the same people who can't write bug-free reference counting code, and since we have very little say in who we work with, we're going to have to continue dealing with stupid bugs of this sort. Even with an ARC, we're going to get people writing stupid code that create memory leaks with cycles and what-not. To fully address this issue at its root, what we really need is a GC, since it eliminates an entire class of memory bugs. Except that the decision makers are hardcore C coders who have irrational GC phobia (and I used to be one of them), so this will probably never happen in *this* job. (Maybe I should consider working for Sociomantic or something...) T -- Truth, Sir, is a cow which will give [skeptics] no more milk, and so they are gone to milk the bull. -- Sam. Johnson
