auto classes and finalizers

[Sean Kelly]

Bruno Medeiros wrote:
> 
> What we want is an allocator that allocates memory that is not to be 
> claimed by the GC (but which is to be scanned by the GC). It's behavior 
> is exactly like the allocator of 
> http://www.digitalmars.com/d/memory.html#newdelete but it should come 
> with the language and be available for all types. With usage like:
> 
>   class LinkedList {
>     ...
>     Add(Object obj) {
>       Node node = mnew Node(blabla);
>       ...
>     }
> 
> Thus, when the destructor is called upon a LinkedList, either 
> explicitly, or by the GC, the Node references will always be valid. One 
> has to be careful now, as mnew'ed object are effectively under manual 
> memory management, and so every mnew must have a corresponding delete, 
> lest there be dangling pointer ou memory leaks. Nonetheless it seems to 
> be only sane solution to this problem.

This does seem to be the most reasonable method.  In fact, it could be 
done now without the addition of new keywords by adding two new GC 
functions: release and reclaim (bad names, but they're all I could think 
of).  'release' would tell the GC not to automatically finalize or 
delete the memory block, as you've suggested above, and 'reclaim' would 
transfer ownership back to the GC.  It's more error prone than I'd like, 
but also perhaps the most reasonable.

A possible alternative would be for the GC to peform its cleanup in two 
stages.  The first sweep runs all finalizers on orphaned objects, and 
the second releases the memory.  Thus in Eric's example on d.D.learn, he 
would be able legally iterate across his AA and close all HANDLEs 
because the memory would still be valid at that stage.

Assuming there aren't any problems with this latter idea, I think it 
should be implemented as standard behavior for the GC, and the former 
idea should be provided as an option.  Thus the user would have complete 
manual control available when needed, but more foolproof basic behavior 
for simpler situations.

> Another interesting addition, is to extend the concept of auto to class 
> members. Just as currently auto couples the lifecycle of a variable to 
> the enclosing function, an auto class member would couple the lifecycle 
> of its member to it's owner object. It would get deleted implicitly when 
> then owner object got deleted. Here is another (made up) example:
> 
>   class SomeUIWidget {
>     auto Color fgcolor;
>     auto Color bgcolor;
>     auto Size size;
>     auto Image image;
>     ...
> 
> The auto members would then have to be initialized on a constructor or 
> something (the exact restrictions might vary, such as being final or not).

I like this idea as well, though it may require some additional 
bookkeeping to accomplish.  For example, a GC scan may encounter the 
members before the owner, so each member may need to contain a hidden 
pointer to the owner object so the GC knows how to sort things out.


Sean