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@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Edouard A. Sent: Tuesday, April 21, 2009 3:51 PM To: boost@lists.boost.org 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