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
|
