Re: [boost] discussion of garbage collection in C++

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

Emil Dotchevski wrote:
> On Sat, Apr 25, 2009 at 10:47 AM, Edward Diener <eldiener_at_[hidden]> wrote:
>> Raindog wrote:
>> 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
> 
> I agree with most of what you're saying, I myself am not a fan of GC
> however I do appreciate its benefits in some cases, when all of the
> resources being managed allow non-deterministic termination (memory
> being the most important such resource.) Yet, occasionally even memory
> needs to be managed deterministically.

I agree with your last statement. See the end of my last paragraph below.

> So I disagree with your
> assertion that classes should be tagged for GC, and not individual
> object instances.

In the ideal scheme classes which encompass non-memory resources should 
actually be tagged as non-GC, so RAII would automatically kick in for 
dynamically allocated objects of those classes; otherwise dynamic 
allocation uses GC.

I also said that there are cases where individual object instances can 
be "tagged" and of course this must be allowed for any object. I just 
think that ideally tagging classes as RAII would cover the majority of 
the situations. Individual object instances, as an example, could occur 
when a container of RAII dynamically allocated objects is created and it 
is then important to "tag" the container itself as RAII, where otherwise 
it would be considered GC by default.

> 
> One of the best features of shared_ptr is the fact that it abstracts
> resource management at object instance level. I know this is wishful
> thinking, but the ideal solution as far as I'm concerned would be to
> implement GC as a custom (non-deterministic) allocation strategy,
> per-instance, as a custom shared_ptr allocator.

I don't think that it is easy to have user of an object decide for every 
object whether it is RAII or GC, which one would have to do with your 
ideally proposed shared_ptr<> custom allocator scheme, unless of course 
shared_ptr were made smart enough to understand the "tag" of the type of 
object it is encompassing and use its custom allocator accordingly in a 
default situation. It is normally much easier for the class designer to 
know whether the class is RAII or not, and much easier for the user of 
an instantiated object of that class just to instantiate the object and 
then not worry whether its destruction is deterministic or not.

The whole point of a system of dynamically allocated memory being a 
smart combination of deterministic RAII and non-deterministic GC is that 
as much of the burden as possible, in determining RAII or GC, should be 
taken off the user of objects as possible so the code is not littered 
with endless manual decisions. Certainly the designer of a class knows 
with 99% certitude whether an object of his class needs RAII or not. In 
the very few run-time cases where a class could encompass either RAII or 
GC objects, or both, ( STL containers are the proverbial example ) then 
the user of that class has to have his say. Similarly if I am allocating 
one million, let's say, instances of GC object in a container, I should 
certainly have the ability of making that container RAII so I can 
release all that memory as soon as possible.