In what circumstances is the destructor of a non-auto class called?

Arcane Jill

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:ca5h0j$5eg$1@digitaldaemon.com...
> In what circumstances is the destructor of a non-auto class called?

1) When 'delete' is called on it.
2) When the garbage collecter collects it.
3) Never.

In article <ca5kd4$a6g$1@digitaldaemon.com>, Walter says...
>
>
>"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:ca5h0j$5eg$1@digitaldaemon.com...
>> In what circumstances is the destructor of a non-auto class called?
>
>1) When 'delete' is called on it.
>2) When the garbage collecter collects it.
>3) Never.

Not (2). You yourself have told me in the past that when the garbage collector collects the object, it may choose not to execute the destructor. So perhaps my question should have been, IF the garbage collector sees that a non-auto class is unreachable, in what circumstances will it CHOOSE to run the destructor?

Sorry for not being clear.

I want to know the circumstance in which a destructor is run, because I want to ENGINEER those circumstances - to create a class for which the garbage collect WILL run the destructor. Is that possible?

Jill

In article <ca5l1a$b20$1@digitaldaemon.com>, Arcane Jill says...
>
>I want to know the circumstance in which a destructor is run, because I want to ENGINEER those circumstances - to create a class for which the garbage collect WILL run the destructor. Is that possible?

That should of course have read "...to create a NON-AUTO class for which..."

Jill

On Wed, 9 Jun 2004 00:18:50 +0000 (UTC), Arcane Jill
<Arcane_member@pathlink.com> wrote:

>In article <ca5kd4$a6g$1@digitaldaemon.com>, Walter says...
>>
>>
>>"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:ca5h0j$5eg$1@digitaldaemon.com...
>>> In what circumstances is the destructor of a non-auto class called?
>>
>>1) When 'delete' is called on it.
>>2) When the garbage collecter collects it.
>>3) Never.
>
>Not (2). You yourself have told me in the past that when the garbage collector collects the object, it may choose not to execute the destructor. So perhaps my question should have been, IF the garbage collector sees that a non-auto class is unreachable, in what circumstances will it CHOOSE to run the destructor?
>
>Sorry for not being clear.
>
>I want to know the circumstance in which a destructor is run, because I want to ENGINEER those circumstances - to create a class for which the garbage collect WILL run the destructor. Is that possible?
>
>Jill

In the Java world finalizers have a bad reputation:
http://www-106.ibm.com/developerworks/java/library/j-jtctips/j-jtc0319a.html
but I think that's because you can't run finalizers by hand like you
can in D. As a result Java finalizers shouldn't do anything important
because you can't rely on them. In D I think it is perfectly ok to
have the destructor do something important as long as the
documentation for the class is very explicit that instances need to be
deleted explicitly otherwise "something important" might not happen,
ever.

D users are smart enough to do the right thing. Or you could just make the class auto if forgetting a delete or two would be so catastrophic.

-Ben

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:ca5l1a$b20$1@digitaldaemon.com...
> In article <ca5kd4$a6g$1@digitaldaemon.com>, Walter says...
> >
> >
> >"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:ca5h0j$5eg$1@digitaldaemon.com...
> >> In what circumstances is the destructor of a non-auto class called?
> >
> >1) When 'delete' is called on it.
> >2) When the garbage collecter collects it.
> >3) Never.
>
> Not (2). You yourself have told me in the past that when the garbage
collector
> collects the object, it may choose not to execute the destructor.

I must have misspoke, because when the gc collects an object, it *does* run the destructor.

> So perhaps my
> question should have been, IF the garbage collector sees that a non-auto
class
> is unreachable, in what circumstances will it CHOOSE to run the
destructor?
>
> Sorry for not being clear.
>
> I want to know the circumstance in which a destructor is run, because I
want to
> ENGINEER those circumstances - to create a class for which the garbage
collect
> WILL run the destructor. Is that possible?

Yes, that is how it works now.

>
> Jill
>
>
>

In article <ca5s60$l06$1@digitaldaemon.com>, Walter says...

>> Not (2). You yourself have told me in the past that when the garbage
>collector
>> collects the object, it may choose not to execute the destructor.
>
>I must have misspoke, because when the gc collects an object, it *does* run the destructor.

How curious. In your post http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/2766, you said:

>There's still another problem, though. D's GC does not *guarantee* that destructors will get run for non-auto objects. Therefore, you might want to keep a list of all the secure arrays created that haven't been wiped yet, then on program close with a module destructor, go through the list and wipe any remaining ones.

Now, I believe you Walter. You wrote the compiler, and I believe you. But, I think these two statements are in contradiction, and now I don't know which one to believe.

Jill

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:ca6ego$1fmt$1@digitaldaemon.com...
> In article <ca5s60$l06$1@digitaldaemon.com>, Walter says...
>
> >> Not (2). You yourself have told me in the past that when the garbage
> >collector
> >> collects the object, it may choose not to execute the destructor.
> >
> >I must have misspoke, because when the gc collects an object, it *does*
run
> >the destructor.
>
> How curious. In your post http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/2766, you said:
>
> >There's still another problem, though. D's GC does not *guarantee* that destructors will get run for non-auto objects. Therefore, you might want
to
> >keep a list of all the secure arrays created that haven't been wiped yet, then on program close with a module destructor, go through the list and wipe any remaining ones.
>
> Now, I believe you Walter. You wrote the compiler, and I believe you. But,
I
> think these two statements are in contradiction, and now I don't know
which one
> to believe.

What isn't guaranteed is the object being collected. If it *is* collected, the destructor will be run.

why not run the destructors all dead objects at the end (in the atexit)? that should solve the problem, no?


In article <ca6g6p$1il6$1@digitaldaemon.com>, Walter says...
>
>
>"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:ca6ego$1fmt$1@digitaldaemon.com...
>> In article <ca5s60$l06$1@digitaldaemon.com>, Walter says...
>>
>> >> Not (2). You yourself have told me in the past that when the garbage
>> >collector
>> >> collects the object, it may choose not to execute the destructor.
>> >
>> >I must have misspoke, because when the gc collects an object, it *does*
>run
>> >the destructor.
>>
>> How curious. In your post http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/2766, you said:
>>
>> >There's still another problem, though. D's GC does not *guarantee* that destructors will get run for non-auto objects. Therefore, you might want
>to
>> >keep a list of all the secure arrays created that haven't been wiped yet, then on program close with a module destructor, go through the list and wipe any remaining ones.
>>
>> Now, I believe you Walter. You wrote the compiler, and I believe you. But,
>I
>> think these two statements are in contradiction, and now I don't know
>which one
>> to believe.
>
>What isn't guaranteed is the object being collected. If it *is* collected, the destructor will be run.
>
>

hellcatv@hotmail.com wrote:

>why not run the destructors all dead objects at the end (in the atexit)?
>that should solve the problem, no?
>  
>
Good idea but some programs never end.

-- 
-Anderson: http://badmama.com.au/~anderson/