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'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. If Boost developers feel that such a thing isn't appropriate for Boost's mission, that's fine. Boost doesn't have to be everything to everyone. However, to say that it wouldn't be useful or is somehow "wrong" is completely misleading, and it's very typical of the "I don't need it so therefore nobody should ever use it" attitude that is so common. Other languages don't use mandatory or opt-in GC strategies because their designers are stupid. They use them because it meets a need that RAII manual memory management doesn't. Of course, RAII manual memory management meets different needs that a GC doesn't. Use the best tool for the job... Gregory Peele, Jr. Applied Research Associates, -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Simonson, Lucanus J Sent: Tuesday, April 21, 2009 2:31 PM To: boost@lists.boost.org Subject: Re: [boost] discussion of garbage collection in C++ Bastek wrote:
struct User; struct Group { std::vector<User*> users; };
struct User { Group* group; };
Taking into account that the data can be used in multiple modules. Do you know when and where to release the memory for this type of objects?
C++ language, enforces restrictions on mapping the structures of databases, because that does not have a Garbage Collector.
Yes. The problem arises because the design is incomplete. Let me finish it for you: struct DataBase { std::list<User> users; std::list<Group> groups; } You release the memory when you release the data base and the code is exception safe and won't leak if you need to destroy the entire database due to a fatal error like screwing up the integrity of those pointers. You can also add and remove users and groups incrementally, of course. Not associating them with a database object is like associating them to a global object. That is bad design. This way you need to know which database you are working with by passing it into the functions that manipulate it (or make them member functions if you are old school), but not having a database object is not having a OO design. I never need to type new and delete to use this design. There is no question that writing C-style code in C++ is harder than writing Java, but that's not a fair comparison. Regards, Luke _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost