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

[Jesse J. <jes...@mi...>]

At 8:16 PM -0600 12/15/02, brian hook wrote:
>  > Hmm, I've seen smart pointers used on several projects and they have
>>  never caused any problems. What sort of "ugly things" are you
>>  referring to?
>
>Assuming that we're defining "smart pointer" as ref-counted,
>templatized pointer access, then here are the typical bugaboos:

Well reference counted smart pointers are probably the most often 
used, but there are also things like std::auto_ptr (useful with 
exceptions) and somewhat more esoteric things (for example I use a 
smart pointer class for preference data that I am very happy with).

>- 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.

>- extremely slack model of ownership (a problem with general GC as well)

That's a feature. :-)

>- cascading destruction if you deref a root node

Why is this a problem?

>- array support can be iffy depending on the implementation

Nah, this is easy to handle as long as you properly define the smart 
pointer's copy ctor and assignment operators (and your array classes 
are coded correctly).

>- cycles

Yeah, that can be a pain but it's not really an issue with smart 
pointers per se.

>- bugs that arise if your implementation doesn't properly handle stack,
>static/global variables, or "special" memory that requires its own de-
>allocation (pointer to surfaces, pointer to AGP memory, etc.)

These are all non-issues in my experience (even the last one: you 
don't delete a surface for example, you delete a class that wraps 
surfaces).

>All that said, there are some pretty solid implementations (Boost?) out
>there that I believe address at least the key issues.

boost:shared_ptr is a good class to look at.

>My gripes are generally more of the subjective stuff -- I think it
>obfuscates code, lends to programmer laziness because there's a poor
>concept of memory ownership and, deep down inside (okay, maybe right
>there at the surface), I just feel that retrofitting automatic memory
>management on a language that was clearly designed for manual memory
>management is a Bad Idea.

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. 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.

   -- Jesse