auto classes and finalizers

[Bruno Medeiros]

kris wrote:
> 
> 
> Regardless of how it's implemented, what's needed is a bit of 
> consistency. Currently, dtors are invoked with two entirely different 
> world-states: with valid state, and with unspecified state. What makes 
> this generally unworkable is the fact that (a) the difference in state 
> is often critical to the operation of the dtor, and (b) there's no clean 
> way to tell the difference.
> 

Hum, from what you said, follows a rather trivial alternative solution 
to the problem: Have the destructor have an implicit parameter/variable, 
that indicates whether it was called explicitly or as a finalizer (i.e, 
in a GC run): (This would be similar in semantics to Sean's suggestion 
of separating the destruction and finalize methods)

class LinkedList {
   ~this() { // called manually/explicitly and automatically
     if(explicit) {
       for( Node n = top; n; ) {
         Node t = n->next;
         delete n;
         n = t;
       }
     }
     // ... finalize here
   }
   ...

Would this be acceptable? How would this compare to other suggestions? I 
can think of a few things to say versus my suggestion.

> 
> As I understand it, the two states correspond to (1) an explicit 
> 'delete' of the object, which includes "auto" usage; and (2) implicit 
> cleanup via the GC.
> 
> The suggestion to restrict dtor to 'auto' classes is a means to limit 
> dtors to #1 above; thus at least making them consistent. However, there 
> are common cases that #1 does not allow for (I'm thinking specifically 
> of object lifetimes that are not related to scope ~ such as time-based). 
> That would need to be addressed somehow?
> 
> Turning to your suggestions ~ the 'marking' of references such that they 
> can be "deleted" multiple times is perhaps questionable, partly because 
> it appears to be specific to the GC implementation? I imagine an 
> incremental collector would have problems with this approach, even if it 
> were workable with a "stop the world" collector? I don't know for sure, 
> but suspect there'd be issues there somewhere.
> 

It works for a stop-the-world collector, I'm sure. As for a incremental 
collector, hum... well, it works if collector guarantees the following:
   * The collector determines a set S of objects to be reclaimed, and no 
object in S is referenced outside of S.


> Whatever the resolution, consistency should be the order of the day.
> 
> - Kris

Manual and automatic memory management are two very different paradigms 
that are likely impossible or impractical to be made "consistent" or 
conciliated, at least in the way you are implying. The "only auto 
classes have destructors" suggestion only makes it "consistent" because 
it limits the usage of the class to only one paradigm (manual management).

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