auto classes and finalizers

[Sean Kelly]

Bruno Medeiros wrote:
> Sean Kelly wrote:
>
>> 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.
>>
> 
> By orphaned objects, do you mean all objects that are to be reclaimed by 
> the GC on that cycle? Or just the subset of those objects, that are not 
> referenced by anyone?

All objects that are to be reclaimed.  I figured your other suggestion 
could be used for more complex cases.

>>> 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.
> 
> Hum, true, it would need some additional bookkeeping, didn't realize 
> that immediately. The semantics like those that I mentioned in me 
> previous post would suffice:
> 
> "When a destructor is called upon an object during a GC (i.e., "as a 
> finalizer"), then the member references are not valid and cannot be 
> referenced, *but they can be deleted*. Each will be deleted iff it has 
> not been deleted already in the reclaiming phase."
> 
> I don't think your algorithm (having a hidden pointer) would be 
> necessary (or even feasible), and the one I mentioned before would suffice.

Hrm... but what if the owner is simply collected via a normal GC run? 
In that case, the GC may encounter the member objects before the owner 
object.  I suppose bookkeeping at the member level may not be necessary, 
but it may result in an extra scan through the list of objects to be 
finalized to determine who owns what.


Sean