Boost logo

Boost :

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


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_at_[hidden]
[mailto:boost-bounces_at_[hidden]] On Behalf Of Simonson, Lucanus J
Sent: Tuesday, April 21, 2009 2:31 PM
To: boost_at_[hidden]
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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk