Re: Smart pointers was RE: [GD-General] Compile times

[brian h. <bri...@py...>]

> >- non-deterministic destruction (a problem with general GC as well)
> 
> How so? With a real GC objects aren't deleted until the collector 
> gets around to freeing them, but with all the ref-counted smart 
> pointer classes I've seen they are deleted when the last reference is 
> released.

Non-deterministic was a poor choice of phrase.  More 
like "unpredictable" because, by definition, if you're using smart 
pointers you've opted to stop thinking about de-allocation of memory.  
So you're never quite sure when the "last reference" is released, since 
that can change as the code evolves.

> >- cascading destruction if you deref a root node
> 
> Why is this a problem?

Because along with "unpredictable de-allocation", it can lead to 
cascades that may cause a hiccup in your system.  If you have 
heavyweight destructors, having a bunch of them called instantly 
because you did this:

foo->pBar = NULL;

is both non-obvious (if you haven't been able to tell, I also abhor 
code that looks straightforward but may actually do a bunch of non-
obvious stuff) and annoying.
 
> Well, what are the options? In my experience automating reference 
> counting with smart pointers is a hell of a lot better than doing it 
> manually. 

My experience has been the opposite.  My anecdote can kick your 
anecdotes ass! =)

> Doing all the memory management manually with naked calls 
> to new and delete is feasible with discipline and some programming 
> conventions, but there are usually a few instances where this becomes 
> difficult.

Where is it difficult to rely on convention and discipline?

-Hook