Dispose then set to nothing

[=?Utf-8?B?SGFvIEppYW5n?=]

Hi,

I see in many MS example code that looks like this

Public Sub Foo()
dim myCustomer as New Customer
...
myCustomer.Dispose()
myCustomer = Nothing
End Sub

I'm wondering if setting myCustomer = Nothing is necessary in this case?
Since myCustomer is a private variable, once it goes out of scope at the next
line, the reference to the object should be released.

Thanks.

Hao

[=?UTF-8?B?R8O2cmFuIEFuZGVyc3Nvbg==?=]

Hao Jiang wrote:

Hi,

I see in many MS example code that looks like this

Public Sub Foo()
dim myCustomer as New Customer
...
myCustomer.Dispose()
myCustomer = Nothing
End Sub

I'm wondering if setting myCustomer = Nothing is necessary in this case?
Since myCustomer is a private variable, once it goes out of scope at the next
line, the reference to the object should be released.

Thanks.

Hao

That is correct. Removing the reference is pointless in this case.

--
Göran Andersson
_____
http://www.guffa.com

[Herfried K. Wagner [MVP]]

"Hao Jiang" <Hao Ji***@discussions.microsoft.comschrieb:

Public Sub Foo()
dim myCustomer as New Customer
...
myCustomer.Dispose()
myCustomer = Nothing
End Sub

I'm wondering if setting myCustomer = Nothing is necessary in this case?

No, it actually isn't necessary for the reason you mentioned.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

[Jay B. Harlow [MVP - Outlook]]

Hao Jiang,
As Göran & Herfried suggests setting myCustomer = Nothing is not needed for
the reason you give.

Instead of calling Dispose outright I would recommend using the new Using
statement in .NET 2.0 (VS 2005). The Using statement ensures that Dispose is
called even if one of the statements contained by the Using throws an
exception.

Public Sub Foo()

Using myCustomer as New Customer

...

End Using

End Sub

Which is basically the following in .NET 1.x:

Dim myCustomer As New Customer
Try
DoSomething()
Finally
If myCustomer IsNot Nothing Then
myCustomer.Dispose()
End If
End Try

--
Hope this helps
Jay B. Harlow [MVP - Outlook]
..NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net
"Hao Jiang" <Hao Ji***@discussions.microsoft.comwrote in message
news:45**********************************@microsof t.com...

Hi,

I see in many MS example code that looks like this

Public Sub Foo()
dim myCustomer as New Customer
...
myCustomer.Dispose()
myCustomer = Nothing
End Sub

I'm wondering if setting myCustomer = Nothing is necessary in this case?
Since myCustomer is a private variable, once it goes out of scope at the
next
line, the reference to the object should be released.

Thanks.

Hao

[Cor Ligthert [MVP]]

Hao Jiang,

Do you mean with MS samples, samples made by Micrsoft, if so can you than
show us some of those?
(URL's)

Because it is not correct, it is as
dim a as integer = 1 + 1
if a <2 then messagebox.show "there was a calculation error"

Thanks in advance,

Cor

"Jay B. Harlow [MVP - Outlook]" <Ja************@tsbradley.netschreef in
bericht news:eI**************@TK2MSFTNGP04.phx.gbl...

Hao Jiang,
As Göran & Herfried suggests setting myCustomer = Nothing is not needed
for the reason you give.

Instead of calling Dispose outright I would recommend using the new Using
statement in .NET 2.0 (VS 2005). The Using statement ensures that Dispose
is called even if one of the statements contained by the Using throws an
exception.

>Public Sub Foo()

Using myCustomer as New Customer

> ...

End Using

>End Sub

Which is basically the following in .NET 1.x:

Dim myCustomer As New Customer
Try
DoSomething()
Finally
If myCustomer IsNot Nothing Then
myCustomer.Dispose()
End If
End Try

--
Hope this helps
Jay B. Harlow [MVP - Outlook]
.NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net
"Hao Jiang" <Hao Ji***@discussions.microsoft.comwrote in message
news:45**********************************@microsof t.com...

>Hi,

I see in many MS example code that looks like this

Public Sub Foo()
dim myCustomer as New Customer
...
myCustomer.Dispose()
myCustomer = Nothing
End Sub

I'm wondering if setting myCustomer = Nothing is necessary in this case?
Since myCustomer is a private variable, once it goes out of scope at the
next
line, the reference to the object should be released.

Thanks.

Hao

[aaron.kempf]

yeah; in vb6 when a variable went out of scope; it automagically
cleaned up after itself
except for DAO-- (which MS just ressurrected)



On Feb 26, 3:30 pm, Hao Jiang <Hao [e-mail]>
wrote:

Hi,

I see in many MS example code that looks like this

Public Sub Foo()
dim myCustomer as New Customer
...
myCustomer.Dispose()
myCustomer = Nothing
End Sub

I'm wondering if setting myCustomer = Nothing is necessary in this case?
Since myCustomer is a private variable, once it goes out of scope at the next
line, the reference to the object should be released.

Thanks.

Hao

[=?Utf-8?B?SGFvIEppYW5n?=]

Thanks Goran, Hefried and Jay! That's what I thought.

Cor, please check out the 2nd and 3rd code section on this MS page:
http://support.microsoft.com/kb/888168

Hao

"Cor Ligthert [MVP]" wrote:

Hao Jiang,

Do you mean with MS samples, samples made by Micrsoft, if so can you than
show us some of those?
(URL's)

Because it is not correct, it is as
dim a as integer = 1 + 1
if a <2 then messagebox.show "there was a calculation error"

Thanks in advance,

Cor

"Jay B. Harlow [MVP - Outlook]" <Ja************@tsbradley.netschreef in
bericht news:eI**************@TK2MSFTNGP04.phx.gbl...

Hao Jiang,
As Göran & Herfried suggests setting myCustomer = Nothing is not needed
for the reason you give.

Instead of calling Dispose outright I would recommend using the new Using
statement in .NET 2.0 (VS 2005). The Using statement ensures that Dispose
is called even if one of the statements contained by the Using throws an
exception.

Public Sub Foo()

Using myCustomer as New Customer

...

End Using

End Sub

Which is basically the following in .NET 1.x:

Dim myCustomer As New Customer
Try
DoSomething()
Finally
If myCustomer IsNot Nothing Then
myCustomer.Dispose()
End If
End Try

--
Hope this helps
Jay B. Harlow [MVP - Outlook]
.NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net
"Hao Jiang" <Hao Ji***@discussions.microsoft.comwrote in message
news:45**********************************@microsof t.com...

Hi,

I see in many MS example code that looks like this

Public Sub Foo()
dim myCustomer as New Customer
...
myCustomer.Dispose()
myCustomer = Nothing
End Sub

I'm wondering if setting myCustomer = Nothing is necessary in this case?
Since myCustomer is a private variable, once it goes out of scope at the
next
line, the reference to the object should be released.

Thanks.

Hao

[Brian Gideon]

On Feb 26, 5:30 pm, Hao Jiang <Hao [e-mail]>
wrote:

Hi,

I see in many MS example code that looks like this

Public Sub Foo()
dim myCustomer as New Customer
...
myCustomer.Dispose()
myCustomer = Nothing
End Sub

I'm wondering if setting myCustomer = Nothing is necessary in this case?
Since myCustomer is a private variable, once it goes out of scope at the next
line, the reference to the object should be released.

Thanks.

Hao

Hao,

To be absolutely precise the object is eligible for garbage collection
even before it goes out of scope as long as it's not used anymore. I
don't know how aggressive the GC rules are specifically, but it is
possible that the GC would consider the line myCustomer = Nothing as
having no side effects on the object and would collect the object even
before the line executed. I suppose it's reasonable to theorize that
the JIT compiler could optimize the line away as well.

Brian

Brian

[Brian Gideon]

On Feb 27, 11:25 am, Hao Jiang <[e-mail]>
wrote:

Thanks Goran, Hefried and Jay! That's what I thought.

Cor, please check out the 2nd and 3rd code section on this MS page:http://support.microsoft.com/kb/888168

Hao

Hmm...yeah, those are poorly written examples.

[Cor Ligthert [MVP]]

Hao,

Thanks, I have sent it further

Cor

"Hao Jiang" <Ha******@discussions.microsoft.comschreef in bericht
news:FA**********************************@microsof t.com...

Thanks Goran, Hefried and Jay! That's what I thought.

Cor, please check out the 2nd and 3rd code section on this MS page:
http://support.microsoft.com/kb/888168

Hao

"Cor Ligthert [MVP]" wrote:

>Hao Jiang,

Do you mean with MS samples, samples made by Micrsoft, if so can you than
show us some of those?
(URL's)

Because it is not correct, it is as
dim a as integer = 1 + 1
if a <2 then messagebox.show "there was a calculation error"

Thanks in advance,

Cor

"Jay B. Harlow [MVP - Outlook]" <Ja************@tsbradley.netschreef in
bericht news:eI**************@TK2MSFTNGP04.phx.gbl...

Hao Jiang,
As Göran & Herfried suggests setting myCustomer = Nothing is not needed
for the reason you give.

Instead of calling Dispose outright I would recommend using the new
Using
statement in .NET 2.0 (VS 2005). The Using statement ensures that
Dispose
is called even if one of the statements contained by the Using throws
an
exception.

Public Sub Foo()
Using myCustomer as New Customer
...
End Using
End Sub

Which is basically the following in .NET 1.x:

Dim myCustomer As New Customer
Try
DoSomething()
Finally
If myCustomer IsNot Nothing Then
myCustomer.Dispose()
End If
End Try

--
Hope this helps
Jay B. Harlow [MVP - Outlook]
.NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net
"Hao Jiang" <Hao Ji***@discussions.microsoft.comwrote in message
news:45**********************************@microsof t.com...
Hi,

I see in many MS example code that looks like this

Public Sub Foo()
dim myCustomer as New Customer
...
myCustomer.Dispose()
myCustomer = Nothing
End Sub

I'm wondering if setting myCustomer = Nothing is necessary in this
case?
Since myCustomer is a private variable, once it goes out of scope at
the
next
line, the reference to the object should be released.

Thanks.

Hao

[Cor Ligthert [MVP]]

Brian,

It is completely inside the method, if the dispose is not there it goes out
of scoop and will be disposed because the method ends.

In my idea it is completely out of sense. (Not that I have the idea that you
have an opposite opinion).

Cor

"Brian Gideon" <br*********@yahoo.comschreef in bericht
news:11*********************@h3g2000cwc.googlegrou ps.com...

On Feb 26, 5:30 pm, Hao Jiang <Hao [e-mail]>
wrote:

>Hi,

I see in many MS example code that looks like this

Public Sub Foo()
dim myCustomer as New Customer
...
myCustomer.Dispose()
myCustomer = Nothing
End Sub

I'm wondering if setting myCustomer = Nothing is necessary in this case?
Since myCustomer is a private variable, once it goes out of scope at the
next
line, the reference to the object should be released.

Thanks.

Hao

Hao,

To be absolutely precise the object is eligible for garbage collection
even before it goes out of scope as long as it's not used anymore. I
don't know how aggressive the GC rules are specifically, but it is
possible that the GC would consider the line myCustomer = Nothing as
having no side effects on the object and would collect the object even
before the line executed. I suppose it's reasonable to theorize that
the JIT compiler could optimize the line away as well.

Brian

Brian

[Brian Gideon]

On Feb 27, 12:00 pm, "Cor Ligthert [MVP]" <[e-mail]>
wrote:

Brian,

It is completely inside the method, if the dispose is not there it goes out
of scoop and will be disposed because the method ends.

In my idea it is completely out of sense. (Not that I have the idea that you
have an opposite opinion).

Cor

I'm not seeing how that's relevant. What I'm saying is that the
object is eligible for collection before the method returns and
possibly before it's variable reference is set to Nothing. And if
that's not true now then there's nothing in the CLI specification that
says a future version can't be that aggressive. Not only is setting
the reference to Nothing unnecessary, it could actually occur *after*
the memory has been released. That's something to consider in the
context of the OP's question.

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

Cor Ligthert [MVP] wrote:

It is completely inside the method, if the dispose is not there it goes out
of scoop and will be disposed because the method ends.

Just to be sure that it doesn't add to the confusion:

Removing the reference to an object and disposing an object are two
completely different things.

--
Göran Andersson
_____
http://www.guffa.com

[Cor Ligthert [MVP]]

Removing the reference to an object and disposing an object are two

completely different things.

Yes going to the toilet and flush the toilet too, but here is an automatic
flushing system, a little bit strange to do it twice.

Cor,
"Göran Andersson" <gu***@guffa.comschreef in bericht
news:%2*****************@TK2MSFTNGP06.phx.gbl...

Cor Ligthert [MVP] wrote:

>It is completely inside the method, if the dispose is not there it goes
out of scoop and will be disposed because the method ends.

Just to be sure that it doesn't add to the confusion:

Removing the reference to an object and disposing an object are two
completely different things.

--
Göran Andersson
_____
http://www.guffa.com

[Brian Gideon]

On Feb 27, 3:17 pm, "Cor Ligthert [MVP]" <[e-mail]>
wrote:

Yes going to the toilet and flush the toilet too, but here is an automatic
flushing system, a little bit strange to do it twice.

Cor,

Cor,

I'm apologize in advance, I'm having a hard time understanding what
you're saying. How does your analogy relate to .NET. What's
happening twice? And how does the concept of disposing an object
relate to the OP's question?

To me anyway, the fact that the OP's question just happened to involve
an object that implements IDisposable was completely irrelevant.

Brian

[Branco Medeiros]

Göran Andersson wrote:
<snip>

Just to be sure that it doesn't add to the confusion:

Removing the reference to an object and disposing an object are two
completely different things.

Maybe this has little to do with the OP's question, but I wonder what
the impact would be for the following scenario:

<aircode>
Sub Bas()
'... code
'... code
If SomeCondition Then
Dim C(VeryHighNumberOfItems) As New SomeClass
'... code
'... code
End If
'... code
'... code
End Sub
</aircode>

In the pseudo-code above, even though the C array is declared inside
the If scope, VB defines the variable at Sub scope. Therefore, it
seems to me that the allocation will remain until the Sub exits...
Shouldn't C() be set to Nothing before leaving the If scope?

Regards,

Branco.

[Brian Gideon]

Branco,

Good question. See my responses inline.

Brian

On Feb 27, 3:41 pm, "Branco Medeiros" <[e-mail]>
wrote:

Maybe this has little to do with the OP's question, but I wonder what
the impact would be for the following scenario:

<aircode>
Sub Bas()
'... code
'... code
If SomeCondition Then
Dim C(VeryHighNumberOfItems) As New SomeClass
'... code
'... code
End If
'... code
'... code
End Sub
</aircode>

In the pseudo-code above, even though the C array is declared inside
the If scope, VB defines the variable at Sub scope. Therefore, it
seems to me that the allocation will remain until the Sub exits...

As does C#. This can be verified by looking at the IL. So your
intuition would be that the memory is allocated for the duration of
the method. But, the GC is pretty smart and can recognize that the C
array is not used anymore outside of the If block. It is eligible for
collection before the remainder of the method executes.

This can cause a very confusing bug when using interop. If you pass
the array into a Win32 API call or something the GC could collect the
object even though the API may still be using it. That's why the
GC.KeepAlive method exists.

Shouldn't C() be set to Nothing before leaving the If scope?

It certainly wouldn't hurt, but it won't help either. Like I said the
GC will recognize that the array isn't used anymore anyway. And the
point I really wanted to drive home was that it is possible that array
could be collected even *before* the line that sets the reference to
Nothing is executed. I suspect in reality it's more likely that the
JIT compiler would just optimize the line away.

Regards,

Branco.

[Herfried K. Wagner [MVP]]

"Brian Gideon" <br*********@yahoo.comschrieb:

To me anyway, the fact that the OP's question just happened to involve
an object that implements IDisposable was completely irrelevant.

I agree. The advice that setting local variables to 'Nothing' at the end of
the procedure or one of its exit points applies to both classes implementing
'IDisposable' and classes not implementing this interface.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

Branco Medeiros wrote:

Göran Andersson wrote:
<snip>

>Just to be sure that it doesn't add to the confusion:

Removing the reference to an object and disposing an object are two
completely different things.

Maybe this has little to do with the OP's question, but I wonder what
the impact would be for the following scenario:

<aircode>
Sub Bas()
'... code
'... code
If SomeCondition Then
Dim C(VeryHighNumberOfItems) As New SomeClass
'... code
'... code
End If
'... code
'... code
End Sub
</aircode>

In the pseudo-code above, even though the C array is declared inside
the If scope, VB defines the variable at Sub scope. Therefore, it
seems to me that the allocation will remain until the Sub exits...
Shouldn't C() be set to Nothing before leaving the If scope?

Regards,

Branco.

There are memory allocated in two ways for that object, with different
life spans.

When the method is called, memory is allocated for the reference C in
the stack frame. This will remain allocated until the method returns and
the stack frame goes away.

When you create the array the memory for it is allocated on the heap.
This memory will remain in use until the last operation in the method
that uses it. Then it's up for garbage collection, and will eventually
be freed.

Eventhough the reference to the object remains in memory until the end
of the method, it's recognised that it's not used beyond the last actual
use of the object.

Clearing the reference will not shorten the time that the memory is in
use. It might in fact prolong the time slightly, if the clearing of the
reference would be considered the last use of the object instead of the
actual last use of the object. I don't know if the code analysis is
clever enough to distinguish between the different ways of using the
reference.

--
Göran Andersson
_____
http://www.guffa.com

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

Cor Ligthert [MVP] wrote:

>Removing the reference to an object and disposing an object are two
completely different things.

Yes going to the toilet and flush the toilet too, but here is an automatic
flushing system, a little bit strange to do it twice.

Cor,

Yes, an increase in temperature and a cow are also two different things,
and that doesn't have anything to do with what I said either.

--
Göran Andersson
_____
http://www.guffa.com

[Jay B. Harlow [MVP - Outlook]]

Cor,

It is completely inside the method, if the dispose is not there it goes
out of scoop and will be disposed because the method ends.

Yes it will eventually be disposed of. At the discretion of the GC. Which
may be in 2 milliseconds or 2 hours depending on GC pressure.

Calling Dispose directly (or indirectly via the Using statement) will ensure
that the object is disposed of immediately! Plus it may reduce GC pressure
as Disposable classes occasionally have a Finalizer. Dispose will commonly
call SuppressFinalize to avoid having the object wait in the Finalization
queue...

Hence the importance of using the Using statement...

--
Hope this helps
Jay B. Harlow [MVP - Outlook]
..NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net
"Cor Ligthert [MVP]" <no************@planet.nlwrote in message
news:um**************@TK2MSFTNGP06.phx.gbl...

Brian,

It is completely inside the method, if the dispose is not there it goes
out of scoop and will be disposed because the method ends.

In my idea it is completely out of sense. (Not that I have the idea that
you have an opposite opinion).

Cor

"Brian Gideon" <br*********@yahoo.comschreef in bericht
news:11*********************@h3g2000cwc.googlegrou ps.com...

>On Feb 26, 5:30 pm, Hao Jiang <Hao [e-mail]>
wrote:

>>Hi,

I see in many MS example code that looks like this

Public Sub Foo()
dim myCustomer as New Customer
...
myCustomer.Dispose()
myCustomer = Nothing
End Sub

I'm wondering if setting myCustomer = Nothing is necessary in this case?
Since myCustomer is a private variable, once it goes out of scope at the
next
line, the reference to the object should be released.

Thanks.

Hao

Hao,

To be absolutely precise the object is eligible for garbage collection
even before it goes out of scope as long as it's not used anymore. I
don't know how aggressive the GC rules are specifically, but it is
possible that the GC would consider the line myCustomer = Nothing as
having no side effects on the object and would collect the object even
before the line executed. I suppose it's reasonable to theorize that
the JIT compiler could optimize the line away as well.

Brian

Brian

[Brian Gideon]

On Feb 27, 5:34 pm, Göran Andersson <[e-mail]:

Clearing the reference will not shorten the time that the memory is in
use. It might in fact prolong the time slightly, if the clearing of the
reference would be considered the last use of the object instead of the
actual last use of the object. I don't know if the code analysis is
clever enough to distinguish between the different ways of using the
reference.

Good point. It's one I hadn't originally considered. If the JIT
compiler doesn't optimize the line away and the GC isn't smart enough
to realize that it doesn't have side-effects then it would be worse
(though I can think worse things) than not having it there at all.
It's yet another reason to avoid doing it.

[Cor Ligthert [MVP]]

Jay,

What advantage is there on a common computer to call dispose immediately or
set things to nothing which will all be done if it is needed in the proper
time by Net.

In contrary, there is time spent to do that and it is in my idea a
disadvantage.

This seems for me always using programs in the way from far back in the past
century.

However on this I get often messages that you have to keep your desktop
cleaned up all the time. I have seen those guys often which at a moment did
nothing else until they were fired.

Cor

"Jay B. Harlow [MVP - Outlook]" <Ja************@tsbradley.netschreef in
bericht news:Os*************@TK2MSFTNGP06.phx.gbl...

Cor,

>It is completely inside the method, if the dispose is not there it goes
out of scoop and will be disposed because the method ends.

Yes it will eventually be disposed of. At the discretion of the GC. Which
may be in 2 milliseconds or 2 hours depending on GC pressure.

Calling Dispose directly (or indirectly via the Using statement) will
ensure that the object is disposed of immediately! Plus it may reduce GC
pressure as Disposable classes occasionally have a Finalizer. Dispose will
commonly call SuppressFinalize to avoid having the object wait in the
Finalization queue...

Hence the importance of using the Using statement...

--
Hope this helps
Jay B. Harlow [MVP - Outlook]
.NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net
"Cor Ligthert [MVP]" <no************@planet.nlwrote in message
news:um**************@TK2MSFTNGP06.phx.gbl...

>Brian,

It is completely inside the method, if the dispose is not there it goes
out of scoop and will be disposed because the method ends.

In my idea it is completely out of sense. (Not that I have the idea that
you have an opposite opinion).

Cor

"Brian Gideon" <br*********@yahoo.comschreef in bericht
news:11*********************@h3g2000cwc.googlegro ups.com...

>>On Feb 26, 5:30 pm, Hao Jiang <Hao [e-mail]>
wrote:
Hi,

I see in many MS example code that looks like this

Public Sub Foo()
dim myCustomer as New Customer
...
myCustomer.Dispose()
myCustomer = Nothing
End Sub

I'm wondering if setting myCustomer = Nothing is necessary in this
case?
Since myCustomer is a private variable, once it goes out of scope at
the next
line, the reference to the object should be released.

Thanks.

Hao

Hao,

To be absolutely precise the object is eligible for garbage collection
even before it goes out of scope as long as it's not used anymore. I
don't know how aggressive the GC rules are specifically, but it is
possible that the GC would consider the line myCustomer = Nothing as
having no side effects on the object and would collect the object even
before the line executed. I suppose it's reasonable to theorize that
the JIT compiler could optimize the line away as well.

Brian

Brian

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

Cor Ligthert [MVP] wrote:

Jay,

What advantage is there on a common computer to call dispose immediately or
set things to nothing which will all be done if it is needed in the proper
time by Net.

I don't think that you fully understand how the disposable objects are
meant to work.

By always calling Dispose on object that implements IDisposable, you
make the memory management efficient.

If you call Dispose, it will remove the object from the finalizer queue,
turning it into an object that can be garbage collected as soon as there
are no references to it. This is very efficient, as all collected
objects in a heap generation is just left in it, and the entire heap
generation is recycled.

If you don't call Dispose, the garbage collector will not free the
object, but instead put it in the queue of objects to be finalized. A
background thread runs the finalizer of the objects in turn, and after
that the objects can be freed by the next garbage collection. As the
object fails the first collection, it will very likely need a move to
the next heap generation, which is done by copying the entire memory
area occupied by the object to the next heap generation.

--
Göran Andersson
_____
http://www.guffa.com

[Brian Gideon]

On Feb 27, 10:36 pm, "Cor Ligthert [MVP]" <[e-mail]>
wrote:

Jay,

What advantage is there on a common computer to call dispose immediately or
set things to nothing which will all be done if it is needed in the proper
time by Net.

In contrary, there is time spent to do that and it is in my idea a
disadvantage.

This seems for me always using programs in the way from far back in the past
century.

However on this I get often messages that you have to keep your desktop
cleaned up all the time. I have seen those guys often which at a moment did
nothing else until they were fired.

Cor

Cor,

In addition to what Goran said calling Dispose, or Close in some
cases, explicitly will release resources held by the object
immediately. This will prevent bugs like locked files held open by a
FileStream because the GC hasn't called Finalize yet.

Brian

[Herfried K. Wagner [MVP]]

Cor,

"Cor Ligthert [MVP]" <no************@planet.nlschrieb:

What advantage is there on a common computer to call dispose immediately
or set things to nothing which will all be done if it is needed in the
proper time by Net.

Imagine an unmanaged resource pool containing only a limited number of
resources of a certain type, such as connections, GDI handles, file handles,
.... By omitting the call to 'Dispose' the application may run out of these
unmanaged resources because they are still locked but not used any more.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

[Cor Ligthert [MVP]]

Herfried,

Did I talk somewhere about resources. That effect I know, for the rest I see
two writers in this thread who mix completely up the finalizing with
disposing and have build their own mythe about that.

They think that using low memory has advantages. Probably they use a
computer with more than 2Gb computer while I am doing fine with my 512Kb
without all those things they are telling.

One of the advantage of Net is the automatic finalizing system at times that
the computer is Iddle.

But some are probably affected it so much that they need computers with more
memory to get some performance.

You know the article Jay wrote about all the discussions here, for sure is
there a big part from my ideas in that article.

Cor

"Herfried K. Wagner [MVP]" <hi***************@gmx.atschreef in bericht
news:en**************@TK2MSFTNGP02.phx.gbl...

Cor,

"Cor Ligthert [MVP]" <no************@planet.nlschrieb:

>What advantage is there on a common computer to call dispose immediately
or set things to nothing which will all be done if it is needed in the
proper time by Net.

Imagine an unmanaged resource pool containing only a limited number of
resources of a certain type, such as connections, GDI handles, file
handles, ... By omitting the call to 'Dispose' the application may run
out of these unmanaged resources because they are still locked but not
used any more.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

[Herfried K. Wagner [MVP]]

"Cor Ligthert [MVP]" <no************@planet.nlschrieb:

Did I talk somewhere about resources. That effect I know, for the rest I
see two writers in this thread who mix completely up the finalizing with
disposing and have build their own mythe about that.

'IDisposable.Dispose' is all about releasing (unmanaged) resources. Well,
and I do not agree with Goran's advice because I believe this is a
micro-optimization. 'IDisposable.Dispose' is not intended as a mechanism to
support deterministic finalization.

They think that using low memory has advantages. Probably they use a
computer with more than 2Gb computer while I am doing fine with my 512Kb
without all those things they are telling.

I agree. However, I think that 'IDisplosable.Dispose' may also be used with
managed resources such as very huge in-memory arrays which are stored inside
certain objects. Take an 1 GB array holding a dictionary in a certain
language, for example. When it's not used any more, it's IMO suitable to
implement 'IDisposable' and let 'Dispose' erase the array.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

[=?windows-1252?Q?G=F6ran_Andersson?=]

Herfried K. Wagner [MVP] wrote:

"Cor Ligthert [MVP]" <no************@planet.nlschrieb:

>Did I talk somewhere about resources. That effect I know, for the rest
I see two writers in this thread who mix completely up the finalizing
with disposing and have build their own mythe about that.

'IDisposable.Dispose' is all about releasing (unmanaged) resources.
Well, and I do not agree with Goran's advice because I believe this is a
micro-optimization. 'IDisposable.Dispose' is not intended as a
mechanism to support deterministic finalization.

What is your opinion that it's intended for, then?

>They think that using low memory has advantages. Probably they use a
computer with more than 2Gb computer while I am doing fine with my
512Kb without all those things they are telling.

I agree. However, I think that 'IDisplosable.Dispose' may also be used
with managed resources such as very huge in-memory arrays which are
stored inside certain objects. Take an 1 GB array holding a dictionary
in a certain language, for example. When it's not used any more, it's
IMO suitable to implement 'IDisposable' and let 'Dispose' erase the array.

There is no reason to dereference managed resources. If an object
contains a large managed structure, just let the object go out of scope
and the entire structure that it contains is immediately eligible for
garbage collection.

Going through the work of dereferncing child objects is totally wasted,
as just letting go of the object does that for you automatically. It's
already built into the garbage collector, so there is no reason to make
another implementation of it in the class, especially as that
implementation always will be less effective.

--
Göran Andersson
_____
http://www.guffa.com

[Herfried K. Wagner [MVP]]

"Göran Andersson" <gu***@guffa.comschrieb:

>>Did I talk somewhere about resources. That effect I know, for the rest I
see two writers in this thread who mix completely up the finalizing with
disposing and have build their own mythe about that.

'IDisposable.Dispose' is all about releasing (unmanaged) resources.
Well, and I do not agree with Goran's advice because I believe this is a
micro-optimization. 'IDisposable.Dispose' is not intended as a mechanism
to support deterministic finalization.

What is your opinion that it's intended for, then?

Releasing (primarily) unmanaged resources.

>>They think that using low memory has advantages. Probably they use a
computer with more than 2Gb computer while I am doing fine with my 512Kb
without all those things they are telling.

I agree. However, I think that 'IDisplosable.Dispose' may also be used
with managed resources such as very huge in-memory arrays which are
stored inside certain objects. Take an 1 GB array holding a dictionary
in a certain language, for example. When it's not used any more, it's
IMO suitable to implement 'IDisposable' and let 'Dispose' erase the
array.

There is no reason to dereference managed resources. If an object contains
a large managed structure, just let the object go out of scope

Well, that's not always possible. Imagine the object can still be reached
which prevents finalization by the garbage collector.

Going through the work of dereferncing child objects is totally wasted, as
just letting go of the object does that for you automatically.

The GC cannot always do it automatically because it thinks the object is
still used (which it is, but it's actually not needed any more).

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

[=?windows-1252?Q?G=F6ran_Andersson?=]

Herfried K. Wagner [MVP] wrote:

"Göran Andersson" <gu***@guffa.comschrieb:

>>>Did I talk somewhere about resources. That effect I know, for the
rest I see two writers in this thread who mix completely up the
finalizing with disposing and have build their own mythe about that.

'IDisposable.Dispose' is all about releasing (unmanaged) resources.
Well, and I do not agree with Goran's advice because I believe this
is a micro-optimization. 'IDisposable.Dispose' is not intended as a
mechanism to support deterministic finalization.

What is your opinion that it's intended for, then?

Releasing (primarily) unmanaged resources.

Yes, that is what you usually do when finalizing an object. As it's you
who trigger the process, and not the garbage collector, makes it
deterministic.

>>>They think that using low memory has advantages. Probably they use a
computer with more than 2Gb computer while I am doing fine with my
512Kb without all those things they are telling.

I agree. However, I think that 'IDisplosable.Dispose' may also be
used with managed resources such as very huge in-memory arrays which
are stored inside certain objects. Take an 1 GB array holding a
dictionary in a certain language, for example. When it's not used
any more, it's IMO suitable to implement 'IDisposable' and let
'Dispose' erase the array.

There is no reason to dereference managed resources. If an object
contains a large managed structure, just let the object go out of scope

Well, that's not always possible. Imagine the object can still be
reached which prevents finalization by the garbage collector.

Yes, if you are going to hold on to the object long after it's unusable,
then of course it won't work that way, but why would you do that? Just
remove the reference to the object, and it all goes away.

>Going through the work of dereferncing child objects is totally
wasted, as just letting go of the object does that for you automatically.

The GC cannot always do it automatically because it thinks the object is
still used (which it is, but it's actually not needed any more).

Yes, it can always do that automatically.

--
Göran Andersson
_____
http://www.guffa.com

[Herfried K. Wagner [MVP]]

"Göran Andersson" <gu***@guffa.comschrieb:

>>>>Did I talk somewhere about resources. That effect I know, for the rest
I see two writers in this thread who mix completely up the finalizing
with disposing and have build their own mythe about that.

'IDisposable.Dispose' is all about releasing (unmanaged) resources.
Well, and I do not agree with Goran's advice because I believe this is
a micro-optimization. 'IDisposable.Dispose' is not intended as a
mechanism to support deterministic finalization.

What is your opinion that it's intended for, then?

Releasing (primarily) unmanaged resources.

Yes, that is what you usually do when finalizing an object. As it's you
who trigger the process, and not the garbage collector, makes it
deterministic.

That's true. However, using 'IDisposable' makes perfect sense because the
unmanaged resources are not under the control of the GC and may be limited.

>>>>They think that using low memory has advantages. Probably they use a
computer with more than 2Gb computer while I am doing fine with my
512Kb without all those things they are telling.

I agree. However, I think that 'IDisplosable.Dispose' may also be used
with managed resources such as very huge in-memory arrays which are
stored inside certain objects. Take an 1 GB array holding a dictionary
in a certain language, for example. When it's not used any more, it's
IMO suitable to implement 'IDisposable' and let 'Dispose' erase the
array.

There is no reason to dereference managed resources. If an object
contains a large managed structure, just let the object go out of scope

Well, that's not always possible. Imagine the object can still be
reached which prevents finalization by the garbage collector.

Yes, if you are going to hold on to the object long after it's unusable,
then of course it won't work that way, but why would you do that?

Maybe it's not done in the code I have written. Normally I do not keep
track where objects are referenced because this would make maintenance and
extension of code more complicated.

Just remove the reference to the object, and it all goes away.

As I said, that's not always possible.

>>Going through the work of dereferncing child objects is totally wasted,
as just letting go of the object does that for you automatically.

The GC cannot always do it automatically because it thinks the object is
still used (which it is, but it's actually not needed any more).

Yes, it can always do that automatically.

Only if the object cannot be reached by the program any more, which may
require removal of references a certain piece of code is not aware of.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

[Brian Gideon]

On Feb 28, 8:32 pm, "Herfried K. Wagner [MVP]" <hirf-spam-me-
[e-mail]:

Just remove the reference to the object, and it all goes away.

As I said, that's not always possible.

I think you guys must be thinking the same thing just saying it
differently.

I think what Goran is saying that it *is* that simple to just stop
referencing an object. Set a variable to Nothing, remove the object
from a Hashtable, ignore the return value of a function, etc. And I
agree with that.

I think what Herfried is saying is that there are rare scenarios where
an a newly created object referenced by a local variable will not be
eligible for collection when the variable goes out of scope and even
if you made absolutely sure that you didn't pass that reference to
another method. This can happen when the object registers itself in a
shared field without the caller's knowledge. Consider this example.

Public Sub DoSomething
Dim a As MyBigObject = New MyBigObject()
End Sub

Even in this simplistic example there's no guarentee that the object
referenced by 'a' will be eligible for collection...ever! Maybe the
class' constructor puts a reference to itself in a static field
internally. And maybe Dispose would be a good place to put code to
dereference the object or place a call to . Personally, I think this
would be better handled by a WeakReference, but I do see what Herfried
is trying to say.

Brian

[Cor Ligthert [MVP]]

An object will be finalized as it has itself no reference or as it has no
reference to it.

Image this

private ar as new arraylist
private sub mysub
Dim a as MyDisposableClass
ar.add(a)
a.dispose
a = nothing
end sub

a will exist as long as that it is not removed from the arraylist

Cor

"Brian Gideon" <br*********@yahoo.comschreef in bericht
news:11**********************@z35g2000cwz.googlegr oups.com...

On Feb 28, 8:32 pm, "Herfried K. Wagner [MVP]" <hirf-spam-me-
[e-mail]:

Just remove the reference to the object, and it all goes away.

As I said, that's not always possible.

I think you guys must be thinking the same thing just saying it
differently.

I think what Goran is saying that it *is* that simple to just stop
referencing an object. Set a variable to Nothing, remove the object
from a Hashtable, ignore the return value of a function, etc. And I
agree with that.

I think what Herfried is saying is that there are rare scenarios where
an a newly created object referenced by a local variable will not be
eligible for collection when the variable goes out of scope and even
if you made absolutely sure that you didn't pass that reference to
another method. This can happen when the object registers itself in a
shared field without the caller's knowledge. Consider this example.

Public Sub DoSomething
Dim a As MyBigObject = New MyBigObject()
End Sub

Even in this simplistic example there's no guarentee that the object
referenced by 'a' will be eligible for collection...ever! Maybe the
class' constructor puts a reference to itself in a static field
internally. And maybe Dispose would be a good place to put code to
dereference the object or place a call to . Personally, I think this
would be better handled by a WeakReference, but I do see what Herfried
is trying to say.

Brian

[Herfried K. Wagner [MVP]]

Cor,

"Cor Ligthert [MVP]" <no************@planet.nlschrieb:

An object will be finalized as it has itself no reference or as it has no
reference to it.

Image this

private ar as new arraylist
private sub mysub
Dim a as MyDisposableClass
ar.add(a)
a.dispose
a = nothing
end sub

a will exist as long as that it is not removed from the arraylist

Yes, as long as the arraylist can be reached.

Your sample is basically showing what I am describing. Sure there are
solutions using weak references, but I like the 'IDisposable' solution more
in certain cases because it works pretty well.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>