When does the Finalize event of a class fire?

[Barry Flynn]

VB 2005.

I have the following code in a Sub.

Dim oFred As SillyClass
oFred = New SillyClass
oFred.Gloop()
oFred = Nothing

Exit Sub

The Finalize code in the class does not fire until the .exe is closed.
I expected it to fire at either:-
- the point at which oFred is set to Nothing, or
- the point at which we exit from the Sub, and variable oFred goes out of
scope.

What are the rules governing when the Finalize code runs?

Thanks

Barry

[Tom Shelton]

On 2008-06-14, Cor Ligthert[MVP] <no************ @planet.nlwrote :

You mistunderstood my message however, something you added is something I
disagree with you.

In my idea you should use dispose as it is needed and were it is made for,
not because that is there given because it is inheritted by component.

But, unless you dive in with reflector, or it is explicitly documented, how do
you know that it isn't necessary? It is definately necessary for many objects
that do inherit from component - how do you distinguish? And what if the
implementation of said object changes in the future?

Sure, I know how to find out if the call is necessary or not - but I
prefere these sort of things to be a black box. I don't really want to know
it's implementation details. And in general, a few clock cycles to make the
call isn't going to noticibly impact the performance.

I have too often read the sentence, it is a method in the class so it is
best practise to use it. I get the idea you write that in a way.

It is for me not good practise to use an method, just because that it is in
a class. I don't use ToString as I need to count two integers.

Dim a as integer = 1
Dim b as integer = 1
Dim C as integer = Cint(a.ToString ) + Cint(b.ToString )

That's sort of stretching the point, Cor. I am sure there aren't many people
who would do such a thing. But, I think the call to dispose falls in the
category of defensive coding and OOP's principle of information hiding...

In that way as is written so often wrong about dispose this above would be
also best practise. For me it's not.

Nobody is advocating calling methods just because they exist.

There is in my idea nothing wrong with doing someting twice as that makes
the total proces shorter, especially as that is done at the best managed
moment.

I'm not sure I get you here? Not calling dispose can negatively affect the
performance of the gc, because it normally has to make two passes to remove and
object that implements idispose if dispose insn't called... That has nothing
to do with being disposable of course - but the fact that most objects that
implement IDisposable also include a finalizer. How is that in anyway a good
thing?

(This including that the "using" automaticly executes dispose, what makes
the using at least more simple to describe)

Using is the same as calling dispose, yes. And I use it :)

Which does not mean that I don't use dispose, I always use that for drawing
objects, dialogforms, etc.

Just my idea.

With which, I respectfully disagree :)

--
Tom Shelton

[Cor Ligthert[MVP]]

Tom,

>
I'm not sure I get you here? Not calling dispose can negatively affect
the
performance of the gc, because it normally has to make two passes to
remove and
object that implements idispose if dispose insn't called... That has
nothing
to do with being disposable of course - but the fact that most objects
that
implement IDisposable also include a finalizer. How is that in anyway a
good
thing?

I have seen that the GC works as the video processor is doing its job, I am
not completely sure of that, but as it is like that, it is in fact null
time, while your dispose takes needed proces time.

I agree that this is not for non video processes. I am working at one at the
moment, it runs at night, nobody cares if it takes 2 or 6 hours.

Cor

[rowe_newsgroups]

On Jun 14, 2:30 pm, "Cor Ligthert[MVP]" <notmyfirstn... @planet.nl>
wrote:

Tom,

I'm not sure I get you here? Not calling dispose can negatively affect
the
performance of the gc, because it normally has to make two passes to
remove and
object that implements idispose if dispose insn't called... That has
nothing
to do with being disposable of course - but the fact that most objects
that
implement IDisposable also include a finalizer. How is that in anyway a
good
thing?

I have seen that the GC works as the video processor is doing its job, I am
not completely sure of that, but as it is like that, it is in fact null
time, while your dispose takes needed proces time.

I agree that this is not for non video processes. I am working at one at the
moment, it runs at night, nobody cares if it takes 2 or 6 hours.

Cor

I'm not sure how many times we've been through this conversation on
the newsgroups, but I'm sure we've covered all your arguments and
proved them to be rooted in misinformation or just plain wrong. I've
also seen this topic enough to know it doesn't really matter what
arguments we give, you aren't going to change your opinions. For this
reason I encourage readers of this thread who want the "full" debate
to do some searching in the archives.

However, just to restate my opinion, I believe you you should use
IDisposable every time unless you are absolutely sure that there is no
reason to call it (such as Cor's example of inherited Components).
This has nothing to do with calling the method simply because it
exists (such as Cor's attempt at saying this through his "ToString"
sample), it has to do with calling the method since the developer's
say it is necessary (even though sometimes it is not). Personnally, I
would not allow code to go to production that does not use the Dispose
functionality where it is needed (db transactions, streams, graphics,
etc). This to me is a worse "no-no" than writing code without having
Option Strict turned on.

Thanks,

Seth Rowe [MVP]

[Cor Ligthert[MVP]]

Seth,

What do you want to say with your complete message. You write exactly how I
think and always write about it.

Even in this thread I have explicitly given situations where it should be
used.

But that as well as you create your own classes where IDispose is not
implemented and unmanaged resources are used.

But not as you always tells to dispose things as datatables, datasets or a
Sqlconnection (the latter has the dispose implemented in the close).

So what do you mean with this cheap agusing message what tells nothing then
some demagogie.

I'm not sure how many times we've been through this conversation on
the newsgroups, but I'm sure we've covered all your arguments and
proved them to be rooted in misinformation or just plain wrong

Cor
"rowe_newsgroup s" <ro********@yah oo.comschreef in bericht
news:8f******** *************** ***********@c65 g2000hsa.google groups.com...

On Jun 14, 2:30 pm, "Cor Ligthert[MVP]" <notmyfirstn... @planet.nl>
wrote:

>Tom,

I'm not sure I get you here? Not calling dispose can negatively affect
the
performance of the gc, because it normally has to make two passes to
remove and
object that implements idispose if dispose insn't called... That has
nothing
to do with being disposable of course - but the fact that most objects
that
implement IDisposable also include a finalizer. How is that in anyway
a
good
thing?

I have seen that the GC works as the video processor is doing its job, I
am
not completely sure of that, but as it is like that, it is in fact null
time, while your dispose takes needed proces time.

I agree that this is not for non video processes. I am working at one at
the
moment, it runs at night, nobody cares if it takes 2 or 6 hours.

Cor

I'm not sure how many times we've been through this conversation on
the newsgroups, but I'm sure we've covered all your arguments and
proved them to be rooted in misinformation or just plain wrong. I've
also seen this topic enough to know it doesn't really matter what
arguments we give, you aren't going to change your opinions. For this
reason I encourage readers of this thread who want the "full" debate
to do some searching in the archives.

However, just to restate my opinion, I believe you you should use
IDisposable every time unless you are absolutely sure that there is no
reason to call it (such as Cor's example of inherited Components).
This has nothing to do with calling the method simply because it
exists (such as Cor's attempt at saying this through his "ToString"
sample), it has to do with calling the method since the developer's
say it is necessary (even though sometimes it is not). Personnally, I
would not allow code to go to production that does not use the Dispose
functionality where it is needed (db transactions, streams, graphics,
etc). This to me is a worse "no-no" than writing code without having
Option Strict turned on.

Thanks,

Seth Rowe [MVP]

[rowe_newsgroups]

I'll do my best to answer your questions Cor, though I am having a bit
of trouble understanding some of what you are saying here.

What do you want to say with your complete message. You write exactly how I
think and always write about it.

The purpose of my message was to encourage readers to find the
previous threads where we have been over this.

Even in this thread I have explicitly given situations where it should be
used.

Again, many of the areas where we differ in opinion is whether or not
you should call Dispose if you do not know whether it is needed. We've
covered this in other threads, and so as to not waste time here I will
not go over it again.

But that as well as you create your own classes where IDispose is not
implemented and unmanaged resources are used.

Are you saying that I never reference unmanaged code in my projects?
If so you are a fool for assuming that I don't do this. And I assure
you that when I reference unmanaged code I implement IDisposable for
cleanup.

But not as you always tells to dispose things as datatables, datasets or a
Sqlconnection (the latter has the dispose implemented in the close).

Close and Dispose methods do different things. Again so as to not
waste time please read the following thread:

http://groups.google.com/group/micro...7e0a66a380a387

So what do you mean with this cheap agusing message what tells nothing then
some demagogie.

I have no idea what demagogie is, but I'll attempt to answer what I
think you are asking.

I'm not sure how many times we've been through this conversation on
the newsgroups, but I'm sure we've covered all your arguments and
proved them to be rooted in misinformation or just plain wrong

Not sure how I could get any clearer. You have listed many arguments
against using the IDisposable pattern as it was intended and I and
many others have shown you in previous threads where you are mistaken,
however I don't think you have ever changed your opinion. Remember
though Cor, just because you don't understand why you are wrong or you
refuse to admit you are wrong does not mean you aren't still wrong.

Some of the many things you have said which I believe are blatantly
wrong are:

That calling Dispose is the same as calling ToString()
The Garbage Collector cleans up any resource better without any
interaction by the developer
The Garbage Collector runs during "idle" times and never affects
performance
Dispose should be avoided unless you absolutely know it must be called
More I'm sure I've forgotten

Again, I'm not going to list rebuttals here, I encourage readers to
use the archives and find the previous threads and form their own
opinions. As for me, I'm dropping this thread.

Thanks,

Seth Rowe [MVP]

[Cor Ligthert[MVP]]

Seth,

snip
http://groups.google.com/group/micro...7e0a66a380a387
snip

In my idea you really should take some more time before you write something.
This was the situation in 2002 were was told that the connection dispose was
overloaded with the removal of the connection from the connectionpool. In
fact that has nothing to do with the dispose. To Implement Dispose to remove
*unmaneged resources* be done by this.

http://msdn.microsoft.com/en-us/libr...tw(VS.85).aspx

Luckely is IDisposable standard implemented in th by the designer created
templates like Form and Component where that is needed.

I have the ides, that what you are talking about all the time is the in my
idea the overloaded Dispose (boolean) method, which is strongly adviced not
to use on its own.

Things as DataTables don't need dispose because it is only a bunch in memory
objects, which have not any unmanaged resource.

By the way, the by you refered message is more times corrected by Pablo
Castro. Here just one I found. Maybe you could use Google in future and not
come direct with something you found from 2002, while giving the idea in
your message that I had to do with it while I was not.

http://groups.google.com/group/micro...11c0671640ad38

Maybe you can use Google to find something Jay B. Harlow wrote, he did made
before he wrote that forever the same discussions like you with me about
dispose.

Then he did some investigation in it and wrote the article. In that article
Jay B. made more clear where dispose should be used. His article was mainly
covering the aspects as I write about dispose. But he added some for me new
aspects, which I use when I write about dispose, by instance the dispose of
the dialogs, which I did but I did not know why before his article.

Cor