www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - How to write a proper class destructor?

reply Bradley Smith <digitalmars-com baysmith.com> writes:
According to the documentation, a class destructor is "expected to 
release any resources held by the object."[1] However, if resources to 
be released are in objects to be garbage collected, "those references 
are no longer valid."[1]

How is a class supposed to release something for which it no longer has 
a valid reference?


   Bradley



[1] http://www.digitalmars.com/d/class.html#destructors.
Jan 24 2007
next sibling parent reply kris <foo bar.com> writes:
Bradley Smith wrote:

 According to the documentation, a class destructor is "expected to 
 release any resources held by the object."[1] However, if resources to 
 be released are in objects to be garbage collected, "those references 
 are no longer valid."[1]
 
 How is a class supposed to release something for which it no longer has 
 a valid reference?
 
 
   Bradley
 
 
 
 [1] http://www.digitalmars.com/d/class.html#destructors.


Yeah, that's a good one :)

Tango has a good resolution for this, that stemmed from long discussion 
on the NG. Those changes never made it into phobos, IIRC
Jan 25 2007
parent reply Bradley Smith <digitalmars-com baysmith.com> writes:
kris wrote:

 Bradley Smith wrote:

 According to the documentation, a class destructor is "expected to 
 release any resources held by the object."[1] However, if resources to 
 be released are in objects to be garbage collected, "those references 
 are no longer valid."[1]

 How is a class supposed to release something for which it no longer 
 has a valid reference?


   Bradley



 [1] http://www.digitalmars.com/d/class.html#destructors.


 
 Yeah, that's a good one :)
 
 Tango has a good resolution for this, that stemmed from long discussion 
 on the NG. Those changes never made it into phobos, IIRC


Isn't the destructor behavior dictated by the language? How can it be 
fixed with a library? Replace or bypass the GC?


Thanks,
   Bradley
Jan 25 2007
next sibling parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Bradley Smith wrote:

 kris wrote:

 Bradley Smith wrote:

 According to the documentation, a class destructor is "expected to 
 release any resources held by the object."[1] However, if resources 
 to be released are in objects to be garbage collected, "those 
 references are no longer valid."[1]

 How is a class supposed to release something for which it no longer 
 has a valid reference?


 [1] http://www.digitalmars.com/d/class.html#destructors.


 Yeah, that's a good one :)

 Tango has a good resolution for this, that stemmed from long 
 discussion on the NG. Those changes never made it into phobos, IIRC


 
 Isn't the destructor behavior dictated by the language? How can it be 
 fixed with a library? Replace or bypass the GC?


*Behavior* is dictated by the language, yes. But the *order* in which 
they're invoked is determined by the library (specifically, the GC) and 
the program (if 'delete' is used). So yes, this may be fixable by 
replacing the GC.
Jan 25 2007
prev sibling parent kris <foo bar.com> writes:
Bradley Smith wrote:

 kris wrote:
 

 Bradley Smith wrote:


 According to the documentation, a class destructor is "expected to 
 release any resources held by the object."[1] However, if resources 
 to be released are in objects to be garbage collected, "those 
 references are no longer valid."[1]

 How is a class supposed to release something for which it no longer 
 has a valid reference?


   Bradley



 [1] http://www.digitalmars.com/d/class.html#destructors.



 Yeah, that's a good one :)

 Tango has a good resolution for this, that stemmed from long 
 discussion on the NG. Those changes never made it into phobos, IIRC


 
 
 Isn't the destructor behavior dictated by the language? How can it be 
 fixed with a library? Replace or bypass the GC?


Aye -- tango has a modified GC with all kinds of goodies.
Jan 25 2007
prev sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Bradley Smith" <digitalmars-com baysmith.com> wrote in message 
news:ep9joi$1mr2$1 digitaldaemon.com...

 According to the documentation, a class destructor is "expected to release 
 any resources held by the object."[1] However, if resources to be released 
 are in objects to be garbage collected, "those references are no longer 
 valid."[1]

 How is a class supposed to release something for which it no longer has a 
 valid reference?


Huuaaaahhh!

I remember someone suggesting that 'scope' be a valid modifier for class 
instance variables, and it'd basically mean "when this class gets destroyed, 
destroy this other instance as well."  Like auto-deletion when you use a 
scope reference in a function:

class ResourceHolder
{
    scope SomeResource mRsrc;

    this(char[] name)
    {
        mRsrc = new SomeResource(name);
    }
}

..

{
    scope holder = new ResourceHolder("a.file");
    ...
} // holder is destroyed here, and so is its mRsrc member.

Another solution would be to change the behavior of the GC so that deletion 
on program end _is_ deterministic.  That is, it'd basically run a collection 
sweep, call finalizers on objects which don't have references to them, and 
keep doing that until nothing is left.  That way, references to other 
classes would always be valid in destructors, since the GC wouldn't collect 
those references until everything that points to them is destroyed.
Jan 25 2007
next sibling parent reply Bradley Smith <digitalmars-com baysmith.com> writes:
Jarrett Billingsley wrote:

 "Bradley Smith" <digitalmars-com baysmith.com> wrote in message 
 news:ep9joi$1mr2$1 digitaldaemon.com...

 According to the documentation, a class destructor is "expected to release 
 any resources held by the object."[1] However, if resources to be released 
 are in objects to be garbage collected, "those references are no longer 
 valid."[1]

 How is a class supposed to release something for which it no longer has a 
 valid reference?


 
 Huuaaaahhh!
 
 I remember someone suggesting that 'scope' be a valid modifier for class 
 instance variables, and it'd basically mean "when this class gets destroyed, 
 destroy this other instance as well."  Like auto-deletion when you use a 
 scope reference in a function:


Is scope a valid modifier for a data member? The documentation states 
"scope cannot be applied to globals, statics, data members, inout or out 
parameters".[2] In my tests, using scope on a data member compiles, but 
doesn't change the behavior.



 
 class ResourceHolder
 {
     scope SomeResource mRsrc;
 
     this(char[] name)
     {
         mRsrc = new SomeResource(name);
     }
 }
 
 ..
 
 {
     scope holder = new ResourceHolder("a.file");
     ...
 } // holder is destroyed here, and so is its mRsrc member.
 
 Another solution would be to change the behavior of the GC so that deletion 
 on program end _is_ deterministic.  That is, it'd basically run a collection 
 sweep, call finalizers on objects which don't have references to them, and 
 keep doing that until nothing is left.  That way, references to other 
 classes would always be valid in destructors, since the GC wouldn't collect 
 those references until everything that points to them is destroyed. 
 


Are you saying that a proper class destructor can't be written without 
modifying the language?


Thanks,
   Bradley


[2] http://www.digitalmars.com/d/attribute.html#scope
Jan 25 2007
next sibling parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Bradley Smith wrote:

 Jarrett Billingsley wrote:

 I remember someone suggesting that 'scope' be a valid modifier for 
 class instance variables, and it'd basically mean "when this class 
 gets destroyed, destroy this other instance as well."  Like 
 auto-deletion when you use a scope reference in a function:


 
 Is scope a valid modifier for a data member?


No, that paragraph was about a suggestion that it *should* be :).


 Another solution would be to change the behavior of the GC so that 
 deletion on program end _is_ deterministic.  That is, it'd basically 
 run a collection sweep, call finalizers on objects which don't have 
 references to them, and keep doing that until nothing is left.  That 
 way, references to other classes would always be valid in destructors, 
 since the GC wouldn't collect those references until everything that 
 points to them is destroyed.


 
 Are you saying that a proper class destructor can't be written without 
 modifying the language?


I think he's saying that it can be fixed by modifying the GC (which 
isn't so much part of the language as it is of the standard library).
Jan 25 2007
prev sibling next sibling parent Kevin Bealer <kevinbealer gmail.com> writes:
Bradley Smith wrote:

 


...

 
 Are you saying that a proper class destructor can't be written without 
 modifying the language?
 
 
 Thanks,
   Bradley
 
 
 [2] http://www.digitalmars.com/d/attribute.html#scope


Some cases like closing a socket or a file opened with the unix open(2) 
are not affected, because the file is identified with an integer, which 
is stored in your class -- you can safely close it.

But, even if the object is a heap object, there exists a fairly simple 
way to do this *without* modifying the GC algorithms.  You can delay the 
destruction until the next GC cycle using a global table -- in the 
example below, the Foo object is never deleted until it is removed from 
the global table, which is done from the destructor, *after* the cleanup 
is done.

Notes:
1. Don't do this for a linked list's next pointer or similar, or you 
will only remove one linked list element per GC run.

2. Look out for cycles -- this is essentially a reference counting 
technique, so cyclical data structures will never be claimed.

3. Don't reorder the lines marked A and B, or use a 'delete f' in the 
destructor because those actions are not safe if the GC runs while your 
destructor is running -- this could happen if this object is manually 
deleted or declared with scope, etc.

class Foo {
     // must be called
     cleanup();
}

class Bar {
     static bool[Foo] pity_the_foo;

     Foo f;

     this()
     {
         f = new Foo;
         pity_the_foo[f] = true;
     }

     ~this()
     {
         f.cleanup(); // A
         pity_the_foo.remove(f); // B
         // delete f; -- Don't do this
     }
}

Kevin
Jan 28 2007
prev sibling parent Kevin Bealer <kevinbealer gmail.com> writes:
Just an addendum to my previous reply - the technique I mention can also 
be used to implement 'weak pointers'.

Kevin
Jan 28 2007
prev sibling parent reply Jonas Kivi <satelliittipupu yahoo.co.uk> writes:
 "Bradley Smith" <digitalmars-com baysmith.com> wrote in message 



 How is a class supposed to release something for which it no longer has a 
 valid reference?




Jarrett Billingsley wrote:

 I remember someone suggesting that 'scope' be a valid modifier for class 
 instance variables, and it'd basically mean "when this class gets destroyed, 
 destroy this other instance as well."  Like auto-deletion when you use a 
 scope reference in a function:
 
 class ResourceHolder
 {
     scope SomeResource mRsrc;
 
     this(char[] name)
     {
         mRsrc = new SomeResource(name);
     }
 }
 
 ..
 
 {
     scope holder = new ResourceHolder("a.file");
     ...
 } // holder is destroyed here, and so is its mRsrc member.
 
 Another solution would be to change the behavior of the GC so that deletion 
 on program end _is_ deterministic.  That is, it'd basically run a collection 
 sweep, call finalizers on objects which don't have references to them, and 
 keep doing that until nothing is left.  That way, references to other 
 classes would always be valid in destructors, since the GC wouldn't collect 
 those references until everything that points to them is destroyed. 
 
 


Hmm, I think I've run into this problem just a few days ago, as my own 
(very basic) LinkedList implementation was getting a little bit heavy on 
the GC. So, I thought I might be able to make it a little bit quicker by 
adding a destructor and deleting the Nodes that point to the actual data 
(the Nodes that the LinkedList has created). But suddenly I wasn't able 
to iterate through the Nodes while in the destructor, and so, I wasn't 
able to delete them. I'm not really sure if the GC is causing the one 
second pauses that I get when I'm on a really heavy load doing thousands 
of LinkedLists and releasing them. Maybe I should try using pure D 
dynamic arrays instead of my own container... Or try Tango when it's 
released. Do the dynamic arrays in D, or the Tango containers use GC?

And about the scope keyword on a class member suggestion: What about the 
"auto" keyword. What's the difference between the auto and the scope 
keywords?

class Any
{
	auto SomeOther m_someOther;

	this()
	{
		m_someOther = new SomeOther();
	}

	~this()
	{
		//automatically deletes m_someOther...
	}
}
Jan 26 2007
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Jonas Kivi wrote:

 And about the scope keyword on a class member suggestion: What about the 
 "auto" keyword. What's the difference between the auto and the scope 
 keywords?


"scope" is for automatic deletion. "auto" is for type inference.
"auto" used to also be for automatic deletion, but its dual purpose was 
annoying, especially when you wanted to have both of its meanings apply 
(which wasn't possible).
"auto" may still do automatic deletion when a type is also supplied, I'm 
not sure, but if so that's just for backwards compatibility. Don't use 
it for that in new code.
Jan 26 2007
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Frits van Bommel" <fvbommel REMwOVExCAPSs.nl> wrote in message 
news:epcrvr$hen$1 digitaldaemon.com...


 "auto" is for type inference.


No ;)

'auto' is the default (hidden) storage class for local variables in a 
function.  So the following declarations are equivalent:

int x;
auto int x;

'auto' is in the same family as 'static', 'const', and 'scope'.  'auto' does 
not do type inference.  Type inference is triggered when there is a storage 
class, but no type.  So these all trigger type inference:

auto x = 5;
static y = 10;
const z = 15;
scope f = new Foo();

'auto' just happens to be the most common of the bunch, and so you see it a 
lot more.  But it doesn't mean "infer the type."


 "auto" may still do automatic deletion when a type is also supplied, I'm 
 not sure, but if so that's just for backwards compatibility. Don't use it 
 for that in new code.


Nope.
Jan 26 2007
parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Jarrett Billingsley wrote:

 "Frits van Bommel" <fvbommel REMwOVExCAPSs.nl> wrote in message 
 news:epcrvr$hen$1 digitaldaemon.com...
 

 "auto" is for type inference.


 
 No ;)
 
 'auto' is the default (hidden) storage class for local variables in a 
 function.  So the following declarations are equivalent:
 
 int x;
 auto int x;
 
 'auto' is in the same family as 'static', 'const', and 'scope'.  'auto' does 
 not do type inference.  Type inference is triggered when there is a storage 
 class, but no type.  So these all trigger type inference:
 
 auto x = 5;
 static y = 10;
 const z = 15;
 scope f = new Foo();
 
 'auto' just happens to be the most common of the bunch, and so you see it a 
 lot more.  But it doesn't mean "infer the type."


Right, forgot about all that for a moment[1]. However, that is how it 
*should* be. And if you follow those rules, it works just fine, so...


[1] Which is weird, since the code I'm currently working on uses 'const' 
for type inference wherever possible ;)
Jan 26 2007
prev sibling parent reply Jonas Kivi <satelliittipupu yahoo.co.uk> writes:
Frits van Bommel kirjoitti:

 Jonas Kivi wrote:

 And about the scope keyword on a class member suggestion: What about 
 the "auto" keyword. What's the difference between the auto and the 
 scope keywords?


 
 "scope" is for automatic deletion. "auto" is for type inference.
 "auto" used to also be for automatic deletion, but its dual purpose was 
 annoying, especially when you wanted to have both of its meanings apply 
 (which wasn't possible).
 "auto" may still do automatic deletion when a type is also supplied, I'm 
 not sure, but if so that's just for backwards compatibility. Don't use 
 it for that in new code.



Ahh, thanks for clearing that up. I changed all the auto-keywords in my 
own projects code to scope. There were some 50 of them. I'm not sure. It 
looked like it had some effect on my program, so maybe the auto keyword 
doesn't even work for it's old purpose anymore? Don't know. But thanks, 
now I only have my destructors unfunctional.
Jan 26 2007
parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Jonas Kivi wrote:

 Frits van Bommel kirjoitti:

 Jonas Kivi wrote:

 And about the scope keyword on a class member suggestion: What about 
 the "auto" keyword. What's the difference between the auto and the 
 scope keywords?


 "scope" is for automatic deletion. "auto" is for type inference.
 "auto" used to also be for automatic deletion, but its dual purpose 
 was annoying, especially when you wanted to have both of its meanings 
 apply (which wasn't possible).
 "auto" may still do automatic deletion when a type is also supplied, 
 I'm not sure, but if so that's just for backwards compatibility. Don't 
 use it for that in new code.


 
 
 Ahh, thanks for clearing that up. I changed all the auto-keywords in my 
 own projects code to scope. There were some 50 of them. I'm not sure. It 
 looked like it had some effect on my program, so maybe the auto keyword 
 doesn't even work for it's old purpose anymore? Don't know. But thanks, 
 now I only have my destructors unfunctional.


Well, one way to make sure a class never gets GC'ed is to make it a 
'scope class'. Then you can only keep references as scope variables, and 
they always get explicitly deleted. The only problem is that you're then 
not allowed to keep them in member variables, just function-local vars.
Jan 26 2007