Boost logo

Boost :

Subject: Re: [boost] request for interest in a garbage collection library
From: Edward Diener (eldiener_at_[hidden])
Date: 2009-04-17 07:59:54


Achilleas Margaritis wrote:
> David Abrahams wrote:
>> on Mon Apr 13 2009, Achilleas Margaritis <axilmar-AT-gmail.com> wrote:
>>
>>> I would appreciate it if people could take a look and share their
>>> opinions on it.
>>
>
>> It's the lack of a programming model that integrates
>> destructors and peoples' legitimate expectations that they will be
>> called to release non-memory resxources. What can you say about the
>> non-memory resources owned by a GC'd object that contains, say, a mutex?
>>
>
> Personally, I don't see why resources like mutexes or files should be
> managed like memory. Resources like that are "binary" resources: they
> have two states (locked/unlocked, opened/closed), which is perfectly
> suited for RAII.

Jumping in here, the problem is that having to mix GC code, which
automatically releases memory in a non-deterministic way, and normal
RAII destructor code, which releases all resources in a deterministic
way, creates two different syntaxes in a C++ program. This would
currently require the programmer to "know" which type of destruction
belongs with which object.

Unless the same external syntax can automatically be used on all
objects, where the classes of those objects which need deterministic
destruction automatically use RAII destruction whereas the classes of
those objects which only need non-deterministic destruction use GC, I do
not think C++ programmers will ever be enthusiastic about using a
garbage collector. At least I know that I won't and will stick with
shared_ptr with the occasional scoped_ptr/weak_ptr until a way to
syntactically unite RAII and GC is accomplished.

GC has successfully masked the fact, in langages/environments like
Python, Ruby, Java, .Net, that it is a very poor system for dealing with
any resource other than memory.


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