auto classes and finalizers

[Georg Wrede]

Sean Kelly wrote:
> 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.

If the above case was written as:

    class SomeUIWidget {
      Color fgcolor;
      Color bgcolor;
      Size size;
      Image image;
      ...

and the class didn't have an explicit destructor, then the only "damage" 
at GC (or otherwise destruction) time would be that a couple of Color 
instances, a Size instance and an Image instance would be "left over" 
after that particular GC run.

Big deal? At the next GC run (unless they'd be pointed-to by other 
things), they'd get deleted too. No major flood of tears here.

Somehow I fear folks are making this a way too complicated thing.