auto classes and finalizers

[Bruno Medeiros]

Georg Wrede wrote:
> 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.

Actually, with any decent GC, all of those objects will be reclaimed on 
the first GC run (and DMD does that). So you are correct that there is 
no difference when running the GC on that object.
But you miss the point. The point (of my suggestions) was to be able to 
have a destruction system that would work "correctly/extensively" both 
when called by a GC cycle, and when called explicitly (outside of a GC 
cycle).
By "correctly/extensively" I mean that the destructor would be able in 
both cases to ensure the destruction of it's owned resources.

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D