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

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

> So, you've actually used manual ref counting Brian?

Yes, and it kinda sucks.  I don't even ref-count in my code.  I just 
know when and where stuff is allocated or freed.  
 
> >Where is it difficult to rely on convention and discipline?
> 
> The biggest problem is that it doesn't scale well. It's yet another 
> thing for new coders to learn and another thing for busy people to 
> remember to do. All other things being equal it's much better to 
> design the system so that you don't have to rely on a convention.

I sympathize and philosophically agree with this point of view, but at 
the same time in my experience there are usually enough trade offs with 
going with the "automated" approach that it simply ends up not being 
worth it.

I strongly feel that relying on discipline and solid interfaces is the 
right way to go, but I do understand it doesn't scale well because as 
teams grow you start getting fewer disciplined programmers and more 
programmers intent on "getting stuff done" instead of *gasp* thinking 
about what they're doing before they do it.

And as you pointed out elsewhere, this also depends a lot on how much 
dynamic memory allocationn you do.  Since I avoid it like the plague to 
minimize memory related errors (counter-argument: if I used a proper 
smart pointer class or GC system I wouldn't have to be so paranoid 
about such errors), it's much less of an issue for me.

In fact, for all my code, nearly all dynamic memory allocation is done 
at startup, all freeing is done at shut down, and there is almost no 
run-time allocation at all.  I try to use the stack as much as possible 
for objects that don't have a long life time.  I end up restricting 
dynamic allocation to when I don't know the size or number of objects I 
need, or if I'm hiding a derived class implementation (i.e. I'm using 
base class pointers and factory methods).

-Hook