Re: [boost] discussion of garbage collection in C++

Subject: Re: [boost] discussion of garbage collection in C++
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2009-04-21 12:44:21

Gregory Peele ARA/CFD wrote:
> In favor of garbage collection in general, though - for some use
> cases, especially those that don't use non-memory resources, it makes
> a lot of sense.  The Boehm guys claim that garbage collection can be
> a significant performance win for workloads involving large numbers
> of small objects, as compared to C++ new / delete - especially in
> multithreaded environments.  It can also greatly speed up prototyping
> complex geometric or graph data structures, where reference counting
> (especially non-intrusively) is a huge performance / memory hit and
> playing the game of "who owns the pointer?" takes more time than
> actually developing the algorithm for your problem domain.   
>
--snip discussion of performance--
> 
> Of course, an internal GC or any pool allocator techniques I've heard
> of don't help with the huge developer and maintainer cost of correctly
> implementing pointer ownership rules for complex cyclical data
> structures without paying the CPU and memory cost of thread-safe
> cycle-safe reference counting.  I spent far more time solving memory
> leaks, dangling pointers, and invalid memory dereferences than I did
> implementing, testing, and correcting actual geometry logic for my
> Delaunay triangulation package, and my only used resource was memory
> so I didn't need deterministic finalization.  Increasing developer
> productivity when used for the right task is where a traditional GC
> really shines, I think. 

I prefer to have a graph object that owns all graph nodes and deallocates them all in its destructor than have "liberated" graph nodes that can be assigned between different graphs.  Stl style is already providing the big productivity boost that GC claims.  Since the graph and geometry data structures are small and many in number it is better (in terms of both space and time) to store them in vectors and copy them around than allocate them dynamically through any mechanism including garbage collection.  I don't think GC offers any advantage over my current style of graph or geometry programming in terms of either productivity or performance of the code generated.  Cyclical ownership is just bad design.  All the objects in the cycle have the same "life" and an object that encapsulates that relationship and can be used to scope them as a unit is the obvious solution, not GC.  If the argument for GC is because it makes bad design less bad, then it can't win over the argument for good design.  

I never have problems with leaks in my graph or geometry algorithms because I never type new and delete execpt in the rarest of circumstances, and even then the ownership is clear and they are deallocated in the destructor of an object, making the code exception safe.  GC solves a problem that does not exist for me.  If other people still have this problem they should learn how to apply C++ in a way that doesn't lead to such problems, not rely on GC to let them implement sloppy design.  C++ can be as productive to program in as Java if you use it well, and memory pooling with RAII will always outperform GC.

Luke