Correct way of using Dispose

  • Thread starter Thread starter kjon
  • Start date Start date
K

kjon

I always dispose any object with the following:
If not (obj1 is nothing) then obj1.dispose

Now I wonder if that is the correct way of disposing an object? Should I use
obj1 = Nothing after the dispose? Pls advice. Thanks.
 
kjon said:
I always dispose any object with the following:
If not (obj1 is nothing) then obj1.dispose

Now I wonder if that is the correct way of disposing an object? Should I use
obj1 = Nothing after the dispose? Pls advice. Thanks.
Click to expand...

Assuming it's a local variable which isn't used again, or an instance
variable in an instance which is about to become eligible for garbage
collection, there's no need to do this.
 
In addition to Marina,

I think see means objects you can set properties to Nothing by instance a
datasource or a binding.
(Or did I misunderstood it Marina?)


Cor
 
Marinawrote:
You do not need to set anything to Nothing. You only needed to do
that in VB6.

Actually, in wasn't even required in VB6 - it was required I think
only as late as VB4 due to a bug in VB4, but was endlessly
perpetuated by well-meaning developers after that.
 
Hi Alex,

What do you want to say with that?

And please send it next time as an answer for Marina, now see maybe does not
see it because you answered a message from me.

I know that document.

Cor
 
AlexS said:
This is standard misconception and recipe for future problems. GC is able to
cope only with limited number of allocations per time unit and is not ideal,
read has limitations. If it is not able to detect that reference could be
freed, related resource might survive through many GC cycles.
Click to expand...

In the vast majority of cases, however, it does *not* help to set
variables to null/Nothing.
See
http://msdn.microsoft.com/architecture/default.aspx?pull=/library/en-us/dnpag/html/scalenet.asp
for additional details.
Click to expand...

Note that that specifically says not to bother with it for local
variables.

In my experience, it's very rare to have members which are unneeded
until the rest of the object becomes eligible for garbage collection.
In fact, I can't remember the last time it made sense to set something
to null just for the sake of garbage collection.
 
In my experience, it's very rare to have members which are unneeded
until the rest of the object becomes eligible for garbage collection.
In fact, I can't remember the last time it made sense to set something
to null just for the sake of garbage collection.
Click to expand...

Like I said it depends on application. Local variables allocated on stack -
I agree, there is not much sense in nulling them. However, I would suggest
to check the topic "Set Unneeded Member Variables to Null Before Making
Long-Running Calls" in the link I recommended. It explains some of caveats
with local variables. Problem is that any heap allocation under certain
conditions can survive GC cycles for very long periods of time. Which
finally can cause troubles. That's why I suggest not to adopt generic rules,
which might work or not. Definition of long call is very application
specific.
HTH

Alex
 
AlexS said:
Like I said it depends on application. Local variables allocated on stack -
I agree, there is not much sense in nulling them. However, I would suggest
to check the topic "Set Unneeded Member Variables to Null Before Making
Long-Running Calls" in the link I recommended. It explains some of caveats
with local variables. Problem is that any heap allocation under certain
conditions can survive GC cycles for very long periods of time. Which
finally can cause troubles. That's why I suggest not to adopt generic rules,
which might work or not. Definition of long call is very application
specific.
Click to expand...

Yes, but I would be wary of variables which can be set to null like
this - usually it indicates something being a member variable which
should have been a local variable in the first place.
 
Back
Top