Garbage Collection, Allocators/Deallocators and

[Ivo Kasiuk]

> >> > Exploring the example a bit further:
> >> > If C's malloc is used instead of GC.malloc then the deallocators also
> >> > are not called and the program runs out of memory. How are the objects
> >> > supposed to get finalized in this case - do I have to use the delete
> >> > keyword explicitly?
> >>
> >> If you use C's malloc, you will also have to use C's free.
> >
> > Yes, obviously. But the deallocator which contains the call to C's free
> > has to be invoked by someone, otherwise it's useless. So that is my
> > question: how should finalization and deallocation get triggered in this
> > scenario (where non-GC memory is used)?
> 
> delete will, as long as it is kept in D, call the deallocator method.
> Unless the allocated memory is not registered with the garbage collector,
> it will be ignored by the garbage collector, and you will have to manually
> delete allocated objects. The point of using C's malloc and free is
> exactly that - the GC will ignore your objects, and you are free to (that
> is, have to) manage their lifetimes yourself.
> 

Thanks for the explanation.
Summing up what I have learned now:
- When GC-allocated memory is used the deallocator is not called when
the GC automatically finalizes the object, but only when the delete
keyword is used explicitly.
- When non-GC memory is used the deallocator is also only called when
the delete keyword is used, and deallocation/finalization is never
triggered automatically.

In other words: the deallocator only ever gets called when the delete
keyword is used. What does this mean if the delete keyword is not kept
in D:
- Will deallocators also be obsolete then?
- Is there any way the regular finalization sequence (i.e. including
automatic invoking of the destructors) can be run for an object that
uses non-GC memory?