Newbie initial comments on D language - destructor usage

[Bill Baxter]

Edward Diener wrote:
> Bill Baxter wrote:
>> Edward Diener wrote:
>>> I have a small nit having to do with a general comment which perhaps I
>>> did not really understand. In the documentation on class destructors 
>>> I read:
>>>
>>> "When the garbage collector calls a destructor for an object of a class
>>> that has members that are references to garbage collected objects, those
>>> references are no longer valid. This means that destructors cannot
>>> reference sub objects. This rule does not apply to auto objects or
>>> objects deleted with the DeleteExpression."
>>
>>> This comment makes perfect sense up to the last sentence. 
>>
>> You should have seen it before I asked for it to be rewritten!
> 
> <g>
> 
>>
>>> Except for a
>>> 'scope' class a destructor can not possibly know how it is being called
>>> so if someone can explain to me how a destructor can know when it is OK
>>> to reference sub-objects or not, I would love to hear about it. I would
>>> have thought that referencing sub-objects in a destructor was just
>>> forbidden unless the class was a 'scope' class and had to reference a
>>> sub-object to possibly release a non-memory resource. But perhaps I am
>>> missing the full meaning of the comment and someone can explicate the
>>> issues involved for me.
>>
>> All it means is that if for whatever reason you _know_ your destructor 
>> was called explicitly, and not indirectly by the GC, then you're ok. 
>> Whether this is of any practical use is another matter.  I guess if 
>> you always hold explicit references to some set of things, then you 
>> know the GC isn't going to collect them, so you could write those 
>> classes to refer to stuff in their destructors.  In other words 
>> "careful memory management" like BCS said so succinctly.
> 
> What is an 'explicit reference to some set of things' ? Can not the GC 
> be destroying your object in a cross-reference situation where the 
> references you hold are no longer guaranteed to exist in the destructor  ?

Sure, I'm just saying if you're very careful about who holds references 
to what then you can guarantee the GC won't clean it up.

class MyClass {
    this(MyOtherClass c) { c_ = c; }
    ~this() { c_.do_something_fun(); }
}
MyOtherClass c;
MyClass d;

void main() {

    c = new MyOtherClass;
    d = new MyClass(c);

    delete d;
}

In this program it is ok for MyClass to be using its c_ in its 
destructor.  There's no way for c_ to have been destroyed already when 
we get to d's constructor *in this program*.

I think this is probably of little practical value, though.  I think all 
Walter wants to say there is that the indeterminate order of destruction 
in a GC world is the only reason why you can't refer to things in your 
destructors.  Other than that, destructors work in a normal 
deterministic C++-ish way.

--bb