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

Subject: Re: [boost] discussion of garbage collection in C++
From: Gregory Peele ARA/CFD (gpeele_at_[hidden])
Date: 2009-04-21 16:23:34

Edouard,

I appreciate your response.  You made the point that I was trying to
make in a much clearer way - GC and RAII are both useful techniques that
have their place and drawbacks.  Many other responses in this thread
seem to think that RAII solves everything without any drawback, and
there is no room or usefulness for other techniques.  The overall
message I wanted to convey is that GC should be an option available to
C++ programmers, and it's to our benefit to have a well-designed,
tested, and reviewed shared library for it.  It's definitely not a magic
bullet, but when used in the correct way, it's a useful tool in a
designer's toolbox.  It can also make a technical lead's life a bit
easier if his developers are primarily Java developers who are
experienced with GC issues, but need C++ performance and shared
libraries for CPU-bound numerical tasks.  :-)

My only experience with C++ GC is Boehm 7.1, which I decided not to use
because I could not get it to cooperate with Valgrind (and submitted a
patch for other very basic issues I found that didn't exactly fill me
with confidence), so the 1 month vs. 4 month comparison was purely
hypothetical, based on much smaller scale experiences I've had with
prototyping the code in Ruby vs. C++.  I probably shouldn't have
carelessly tossed that out there.  I recently completed a task that took
4 months to design, implement, and test without a GC, the majority of
which was spent designing and debugging memory ownership for a workload
that is a classic example for GC advocates (millions of small objects
mostly composed of pointers with lots of reference cycles)  Perhaps I
would have run into different memory management issues with a GC - as
you pointed out, they come with plenty of traps of their own.  And
solving GC memory leaks isn't necessarily easier than manual memory
leaks.  I would have liked to have the choice, though.

Gregory Peele, Jr.
Applied Research Associates, Inc.

-----Original Message-----
From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]] On Behalf Of Edouard A.
Sent: Tuesday, April 21, 2009 3:51 PM
To: boost_at_[hidden]
Subject: Re: [boost] discussion of garbage collection in C++

Hi Gregory,

GC is an approach at solving resources management. It works very well in
many cases. As you seem to be versed in the area, you also know that it
can
go horribly wrong resulting in terrible performances and massive memory
usage. These cases must be debugged and take a lot of time and can hit
you
very late in project (read: when switching to production).

GC will not prevent you from correctly designing your project and being
careful with resource management. A GC is a program, and as such, has to
be
correctly used to function properly. There is no "magic". You still need
to
plan in advance, be rigorous and anticipate the bandwidth.

RAII and smart pointers are a different approach at resources
management. It
works very well in many cases. Like a GC, it needs to be used correctly
to
function properly. 

> This approach obviously works, and is simple for toy cases like this.
> It becomes quite a bit less simple in real software.  Yes, every
> software design should be capable of being broken up in such a way.
> But
> sometimes doing so is pure hell on your interface encapsulation, or
> comes with highly nontrivial costs, or maybe you'd rather use the GC
to
> accomplish the same task in 1 month instead of 4 months so you can
> spend
> more of your time on stuff your customer actually cares about.

I would like to be presented with a C++ project that takes 1 month with
a
GC, 4 months with RAII. Most surprising. Not to say I encountered every
possible projects in my life, but I'm extremely surprised. I've worked
on
many different projects and every time I had a resource management
issue,
with garbage collected languages it took a different form, but
nevertheless,
it occurred.

> I'm not going to dispute that it's always possible to design good
> software packages without a GC, and I think that you should always
> consider non-GC designs first (not that we have much of a choice in
C++
> at this point, which is the problem under discussion.)  But especially
> for prototypes where proving algorithm feasibility is more important
> than clean design, or in the real world where we don't have unlimited
> time to develop and deliver our software using developers who aren't
> necessarily C++ programming gods, a GC could make life much easier by
> ensuring that we could rely on "good enough" automated memory
> management.

C++ is not a silver bullet and maybe your solution needs to be
implemented
with a different tool.

Kind regards.

-- 
Edouard Alligand
Partner
Bureau 14 SARL - http://www.bureau14.fr/
_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost