www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Destructing Member Objects

reply Brian White <bcwhite pobox.com> writes:
I understand that you're not supposed to delete member within the 
destructor because, when called via the GC, it's possible that object 
has already been destructed.

Is there a way for the object to determine if it's being destructed as 
part of a GC run or if it's being deleted explicitly?

-- Brian
Apr 05 2008
next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Brian White" <bcwhite pobox.com> wrote in message 
news:ft8iuk$qvm$1 digitalmars.com...

I understand that you're not supposed to delete member within the 
destructor because, when called via the GC, it's possible that object has 
already been destructed.

 Is there a way for the object to determine if it's being destructed as 
 part of a GC run or if it's being deleted explicitly?

 -- Brian


Suggested, lauded, unread, forgotten.

Just like most proposed features for D.
Apr 05 2008
prev sibling next sibling parent reply Lionello Lunesu <lio lunesu.remove.com> writes:
Brian White wrote:

 I understand that you're not supposed to delete member within the 
 destructor because, when called via the GC, it's possible that object 
 has already been destructed.


:O really? Where can I find more information about this?

I think it's odd that a member can get deleted before a class that 
contains it. That class still has a valid pointer to it, right? So the 
GC could not have finalized it.. ???

L.
Apr 05 2008
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Lionello Lunesu" <lio lunesu.remove.com> wrote in message 
news:ft9350$23n8$1 digitalmars.com...

 Brian White wrote:

 I understand that you're not supposed to delete member within the 
 destructor because, when called via the GC, it's possible that object has 
 already been destructed.


 :O really? Where can I find more information about this?

 I think it's odd that a member can get deleted before a class that 
 contains it. That class still has a valid pointer to it, right? So the GC 
 could not have finalized it.. ???

 L.


http://www.digitalmars.com/d/1.0/class.html#destructors

"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 is because that the garbage collector does not collect 
objects in any guaranteed order, so there is no guarantee that any pointers 
or references to any other garbage collected objects exist when the garbage 
collector runs the destructor for an object. This rule does not apply to 
auto objects or objects deleted with the DeleteExpression, as the destructor 
is not being run by the garbage collector, meaning all references are 
valid."

The spec doesn't really specify _why_ destruction order is nondeterministic, 
however.  You need nondeterministic destruction in order to break cycles. 
So if A points to B and B points to A, you have a cycle.  In order to break 
the cycle you have to delete one or the other first.  There's no "correct" 
order to destroy them.  So, to solve this, you simply cannot guarantee that 
when an object's destructor is run, that everything that it points to is 
still valid.

(Note, however, that system resources (file handles, Windows COM interfaces, 
sockets, things like that) _can_ be referenced since they weren't allocated 
on the GC heap.  The only problem there is _when_ they're referenced, since 
there's no guarantee that the object containing the reference to the system 
resource will be collected in any timely fashion.)
Apr 05 2008
next sibling parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Sun, 06 Apr 2008 06:27:52 +0200, Jarrett Billingsley  
<kb3ctd2 yahoo.com> wrote:


 The spec doesn't really specify _why_ destruction order is  
 nondeterministic,
 however.  You need nondeterministic destruction in order to break cycles.
 So if A points to B and B points to A, you have a cycle.  In order to  
 break
 the cycle you have to delete one or the other first.  There's no  
 "correct"
 order to destroy them.  So, to solve this, you simply cannot guarantee  
 that
 when an object's destructor is run, that everything that it points to is
 still valid.


It's worth noting that even if only one object in a relation points to
another (i.e. no cycle), the easiest thing for the GC to do is to flag both
as trash, then destroy them in some order when it gets to that point. If it
were to flag only the mother class and destroy that, its child classes  
might
have to wait until the next GC run before they're deleted.

-- Simen
Apr 06 2008
parent reply Christopher Wright <dhasenan gmail.com> writes:
Simen Kjaeraas wrote:

 On Sun, 06 Apr 2008 06:27:52 +0200, Jarrett Billingsley 
 <kb3ctd2 yahoo.com> wrote:
 

 The spec doesn't really specify _why_ destruction order is 
 nondeterministic,
 however.  You need nondeterministic destruction in order to break cycles.
 So if A points to B and B points to A, you have a cycle.  In order to 
 break
 the cycle you have to delete one or the other first.  There's no 
 "correct"
 order to destroy them.  So, to solve this, you simply cannot guarantee 
 that
 when an object's destructor is run, that everything that it points to is
 still valid.


 
 It's worth noting that even if only one object in a relation points to
 another (i.e. no cycle), the easiest thing for the GC to do is to flag both
 as trash, then destroy them in some order when it gets to that point. If it
 were to flag only the mother class and destroy that, its child classes 
 might
 have to wait until the next GC run before they're deleted.
 
 -- Simen


That doesn't work. The collector flags stuff only as not-trash, never as 
trash. Then it does a linear scan through each block containing 
aggregate types and calls destructors.

Well, maybe not, but that's how I'd implement it, if I cared about 
efficiency.
Apr 06 2008
parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Mon, 07 Apr 2008 03:46:31 +0200, Christopher Wright  
<dhasenan gmail.com> wrote:


 Simen Kjaeraas wrote:

 On Sun, 06 Apr 2008 06:27:52 +0200, Jarrett Billingsley  
 <kb3ctd2 yahoo.com> wrote:


 The spec doesn't really specify _why_ destruction order is  
 nondeterministic,
 however.  You need nondeterministic destruction in order to break  
 cycles.
 So if A points to B and B points to A, you have a cycle.  In order to  
 break
 the cycle you have to delete one or the other first.  There's no  
 "correct"
 order to destroy them.  So, to solve this, you simply cannot guarantee  
 that
 when an object's destructor is run, that everything that it points to  
 is
 still valid.


  It's worth noting that even if only one object in a relation points to
 another (i.e. no cycle), the easiest thing for the GC to do is to flag  
 both
 as trash, then destroy them in some order when it gets to that point.  
 If it
 were to flag only the mother class and destroy that, its child classes  
 might
 have to wait until the next GC run before they're deleted.
  -- Simen


 That doesn't work. The collector flags stuff only as not-trash, never as  
 trash. Then it does a linear scan through each block containing  
 aggregate types and calls destructors.

 Well, maybe not, but that's how I'd implement it, if I cared about  
 efficiency.


You're probably right. My point was only that even if there is no circular
reference, there's still a reason to have nondeterministic destruction.
Apr 06 2008
prev sibling parent "Lionello Lunesu" <lionello lunesu.remove.com> writes:
"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
news:ft9jg0$b3h$1 digitalmars.com...

 http://www.digitalmars.com/d/1.0/class.html#destructors



Thanks for that link, I should have been able to find that myself :S

Guess that's a reason MS has decided to create a separate Dispose() for 
RAII, but I'm sure D could do a better job than that.

L.
Apr 07 2008
prev sibling parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Sat, 05 Apr 2008 21:12:18 +0200, Brian White <bcwhite pobox.com> wrote:


 I understand that you're not supposed to delete member within the  
 destructor because, when called via the GC, it's possible that object  
 has already been destructed.

 Is there a way for the object to determine if it's being destructed as  
 part of a GC run or if it's being deleted explicitly?

 -- Brian



class foo
{
   private ~this()
   {
   }

   public kill()
   {
   // call any specific code you want here
   delete this;
   }
}

Then use foo.kill() instead of delete foo. Ugly, but works, I think.
Apr 05 2008
parent reply Brian White <bcwhite pobox.com> writes:
 class foo
 {
   private ~this()
   {
   }
 
   public kill()
   {
   // call any specific code you want here
   delete this;
   }
 }
 
 Then use foo.kill() instead of delete foo. Ugly, but works, I think.


I don't think it does work.  If you have a "scope" variable, for 
example, the compiler won't call "kill" when deleting the object.

-- Brian
Apr 05 2008
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Brian White" <bcwhite pobox.com> wrote in message 
news:ft9oil$j0a$1 digitalmars.com...

 class foo
 {
   private ~this()
   {
   }

   public kill()
   {
   // call any specific code you want here
   delete this;
   }
 }

 Then use foo.kill() instead of delete foo. Ugly, but works, I think.


 I don't think it does work.  If you have a "scope" variable, for example, 
 the compiler won't call "kill" when deleting the object.


You'd have to do it yourself.

{
    auto f = new foo();
    scope(exit) f.kill();

    // ...
}
Apr 06 2008