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.