Subject: Re: [boost] discussion of garbage collection in C++
From: Edouard A. (edouard_at_[hidden])
Date: 2009-04-21 15:50:52
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
> 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.
> 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
> 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,
> 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
C++ is not a silver bullet and maybe your solution needs to be implemented
with a different tool.
-- Edouard Alligand Partner Bureau 14 SARL - http://www.bureau14.fr/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk