Boost logo

Boost :

Subject: Re: [boost] discussion of garbage collection in C++
From: Edward Diener (eldiener_at_[hidden])
Date: 2009-04-25 13:47:49


Raindog wrote:
> Mathias Gaunard wrote:
>> Simonson, Lucanus J wrote:
>>
>> Why stop half way? Why not have an open source C++ runtime
>> environment if the goal is applications programming and rapid
>> prototyping in C++ with open source components? An open source GC
>> library is a good building block for such a system, and of course we'd
>> prefer to implement it in C++.
>>
>> Why build a runtime environment based on GC when you can make a better
>> one that is not?
>>
> Because the majority of programmers have proven that they obviously
> prefer a GC environment over an RAII one. Given that a large number of
> C++ programmers don't even take advantage of RAII, I would say that a
> c++ runtime w/ GC and RAII would be very appealing to a larger number of
> people.

Whenever anyone writes "the majority of programmers..." one can discount
the subsequent statement "the majority" of the time.

.Net, Java, Python, Perl, Ruby, D et al automatically provide GC.
Wonderful for non-deterministic memory management, poor to hopeless for
any other form of resource management. C++ provides RAII resource
management using smart pointers, with boost::shared_ptr<T> probably
being used by quite a few C++ programmers worldwide. C++ is wonderful
for all forms of resource management in general, but much more difficult
for cross-referenced memory management, where boost::weak_ptr<T> offers
one solution.

Microsoft and Sun and other languages decided that their programmers did
not want to have to think about memory management at all, fair enough,
and would live with half-baked or programmer hand-rolled solutions to
other resource management issues. So GC, that emperor with a big hole
covering his nakedness, is all the popular rage and everyone pretends
that the hole does not exist or is adequately covered with a nice patch.

RAII and GC in C++ ? Sure, as long as today GC is strictly optional. But
I, who have run into resource management issues much, much more often in
my programming of non-C++ computer languages than I have run into
cross-referencing memory issues programming in C++ will stick with C++
smart pointers. Currently mixing C++ RAII and GC in C++ is a headache I
do not want. Good luck to others in using them both, in other words in
mixing deterministic and non-deterministic destruction and being happy
that everything is used correctly ( RAII objects holding GC objects and
vice versa, containers of RAII objects holding GC objects and vice versa ).

That is why I think that a real solution to using RAII and GC in C++
must come from the ability to tag objects at the class level, and only
occasionally at the object level, as a non-memory resource holding
object, and that the syntax for doing dynamic memory management in C++
must encompass both smart pointers and GC allocations of memory under
the same mnemonics. In the ideal case a programmer should only have to
create an object and then forget about having to manually delete it, and
either RAII smart pointers kick in for deterministic destruction when
non-memory resources have to be released or GC kicks in for
non-deterministic destruction of objects when only memory is involved.
That ideal case should exist for all languages, but Microsoft, Sun, and
others want to pretend that GC is good enough. It isn't, and it has been
one of the biggest frauds in computer programming in pretending that it is.


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