> >> > 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?
