Smart pointers instead of GC?

[H. S. Teoh]

On Tue, Feb 04, 2014 at 01:11:23PM +1000, Manu wrote:
> On 4 February 2014 12:05, Nick Sabalausky <
> SeeWebsiteToContactMe at semitwist.com> 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