When should I implement IDispose?

[Guest]

I have several custom classes in my app that have a definite lifetime. During the course of runtime, there will be a few thousand of these objects allocated. The objects have a definite lifetime: they will be used until the user intervenes, at which point they should be deleted from memory

Given that these thousands of objects all have a definite lifetime, and yet, they do NOT have any unmanaged resources or data streams, should I implement IDisposable? If so, should I null out all reference types in the .Dispose method? The Java programmer in me says yes, but I'm unsure if and when I should implement IDisposable.

 

[Jon Skeet [C# MVP]]

I have several custom classes in my app that have a definite
lifetime. During the course of runtime, there will be a few thousand
of these objects allocated. The objects have a definite lifetime:
they will be used until the user intervenes, at which point they
should be deleted from memory.

And at that point will they still be referenced?

Given that these thousands of objects all have a definite lifetime,
and yet, they do NOT have any unmanaged resources or data streams,
should I implement IDisposable? If so, should I null out all
reference types in the .Dispose method? The Java programmer in me
says yes, but I'm unsure if and when I should implement IDisposable.

The Java programmer in you is wrong, both in Java and C#.

If you've got no unmanaged resources, nor any references to other
objects which need disposing, then you almost certainly don't want a
Dispose method.

Depending on your exact situation, you may want to null out some
references *to* your objects if they're in variables which are still
"live", but again that's rarely necessary.

 

[Cor]

Hi Garbriel,

If it are big objects, let say tif images, I definatly would do that.

Otherwise I would wait to see what it did mean.

My thinking is always, why should the program make a trip to the
operatingsystem to do the disposing, while there is still memory enough?

Let it be done in a nice garbage sweep.

But just my thought,

Cor

 

[Jon Skeet [C# MVP]]

If it are big objects, let say tif images, I definatly would do that.

Otherwise I would wait to see what it did mean.

My thinking is always, why should the program make a trip to the
operatingsystem to do the disposing, while there is still memory enough?

Let it be done in a nice garbage sweep.

Memory is only one resource though - handles are somewhat different.
It's not a good idea to have handles open for longer than you need to,
as "pressure" on the number of available handles won't cause the
garbage collector to fire in the same way that pressure on memory will:
instead, programs will just fail.

 

[Cor]

Hi Jon,

It's not a good idea to have handles open for longer than you need to.

Thanks,

Can you explain why not.

Cor

 

[Jon Skeet [C# MVP]]

Thanks,

Can you explain why not.

Um, I did in the rest of the post. Handles are a limited system
resource, basically.

 

[Cor]

Hi Jon,

Um, I did in the rest of the post. Handles are a limited system
resource, basically.

I did not see that, I saw that you told it would not force the the garbagde
collector to start if it where in your opinion to much, but you did not tell
why it was not a good idea to have handles open for longer than you need
to, as you wrote.

Cor

 

[AnonymousHoward]

A handle is a way to open and close system resources. Resources can be
graphic objects, files, mutexes, etc. They take up system space like memory
for example. The resource the handle points to does not influence the
garbage collector.

 

[Cor]

Hi Howard,

A handle is a way to open and close system resources. Resources can be
graphic objects, files, mutexes, etc. They take up system space like memory
for example. The resource the handle points to does not influence the
garbage collector.

But if there is still 16Gb memory free, is that than important?

That was the question.

Cor

 

[AnonymousHoward]

But if there is still 16Gb memory free, is that than important?

That was the question.

I don't see where anyone said there is any amount of memory free or
available. Maybe I missed it?

What I did see is Gabriel's statement "The objects have a definite lifetime:
they will be used until the user intervenes, at which point they should be
deleted from memory."

If he had handles to operating system resources, and he wanted those
resources reclaimed when the user intervenes then yes implement IDispose,
those resources would reclaimed then and not when the garbage collector gets
around to it. If there are no handles to operating system resources then I
would say no let the garbage collector do it.

 

[Lloyd Sheen]

Ok, I don't understand how implementing the IDisposable does anything.

I have an object. I create it and then set the reference to nothing. I
have a dummy line for debugging in the finalize and Dispose subs but until I
close the app neither is called. When I close the app the Finalize is
called but the Dispose is never called.

So basically we are at the wim of the GC.

Lloyd Sheen

 

[AnonymousHoward]

It has to be called explicity or the object in question can be used within
the using statement in which dispose would be called automatically. Its not
fool proof because developers forget or don't realize they should be calling
it, but it is a way for cleaning up resources in a deterministic way that
are not collected by the garbage collector.

 

[Lloyd Sheen]

Ok, a question then.

We had in VB6 a class called WaitCursor. When an operation would take a
long time at the beginning of a subroutine create an instance of WaitCursor.
This would change the cursor to a wait cursor (there are more details but
not important).

When the variable would go out of scope the Terminate would be called and
the Object would figure out what to do. Now this is broken. I think that
all Dispose is a common name to call. Since the developer must call it, and
that can be missed there seems to be no way in the framework to take
advantage of the Constructor/Destructor pattern for objects.

Lloyd Sheen

 

[AnonymousHoward]

I think that all Dispose is a common name to call. Since the developer
must call it, and

that can be missed there seems to be no way in the framework to take
advantage of the Constructor/Destructor pattern for objects.

Thats the way I see it too.

Now this is broken.

Well I come from a C++ background, if an object was created with a new and
went out of scope without a delete, that was a memory leak. Even with COM
you had to make sure you decremented your object's reference count to
prevent memory leaks. While there were helper classes for both these
situations it still happened. So from my point of view nothing is broken.
Its just a different memory bookkeeping model. I consider it better but you
are still forced to know whats going on in the CLR to make things efficient.
If you are coming from a VB background you may not see it this way and I
understand why.

 

[Cor]

Hi Howard,

If you are coming from a VB background you may not see it this way and I
understand why.

What is that what you understand, I am curious what you mean with the
sentence above?

In my opinion it looks if you are making the often made fault from people
making programs, who have a small scoop on the different OS that are/have
been and programming languages.

They think often that solutions for failures in one programming language or
OS are universal solutions for all failures.

One of the purposes from managed code (I am only talking about managed code)
is to overcome those failures and prevent by instance memory leaks.

And therefore my question again, why do you want to manage the managing code
by hand, what is the advantage?

Cor

 

[AnonymousHoward]

If you are coming from a VB background you may not see it this way and I

What is that what you understand, I am curious what you mean with the
sentence above?

VB had a more deterministic way of cleaning up resources. I believe it has
reference counting. I'm not saying its better or worse, reference counting
has its problems too. I'm saying when all references to an object went away,
the object was cleaned up. I believe this is what Lloyd was complaining
about. Garbage collection on the other hand, the object is cleaned up when
the garbage collector gets around to it.

In my opinion it looks if you are making the often made fault from people
making programs, who have a small scoop on the different OS that are/have
been and programming languages.

They think often that solutions for failures in one programming language or
OS are universal solutions for all failures.

They think often that solutions for failures in one programming language or
OS are universal solutions for all failures.

I have built real-time and enterprise solutions in Unix/Windows/Linux with
C,C++,Perl,Java,VB and now C#/VB.NET.

And therefore my question again, why do you want to manage the managing code
by hand, what is the advantage?

Where do I say I want do that? I don't say that and I don't want to do that.

Just because the garbage collector takes care of most of the memory
problems, it does not take care of ALL the problems. Look around the message
boards, people complain about memory consumption all the time, its one of
the main complaints. There have been gazillion articles on understanding the
CLR, garbage collection, and memory consumption, along with best programming
practices. Many by MS insiders and experts. Memory consumption is an issue,
there things you should and should not do.

Example, when you get a .NET graphics object, it is a managed object, but
what should be the first thing you do with it when you are done with it. You
should call Dispose to release the underlying OS resources, in no way should
you let the garbage collector control the destruction of these resources,
this documented and suggested by MS themselves. Why? Because a managed
object could have a single handle property that points to a gigabyte sized
OS resource. What does the garbage collector see as the size of the object?
Ignoring the CLR overhead for the object itself, it thinks the size of the
object is 32 bits (or 64 if running on the 64 bit system). Will the garbage
collector be in a hurry to destroy this object? No, but in the meantime 1
gig of your memory is consumed by this dead object. Graphics object is not
the only "managed" object that has handles to OS resources.

 

[Cor]

VB had a more deterministic way of cleaning up resources. I believe it has

reference counting. I'm not saying its better or worse, reference counting
has its problems too. I'm saying when all references to an object went away,
the object was cleaned up. I believe this is what Lloyd was complaining
about. Garbage collection on the other hand, the object is cleaned up when
the garbage collector gets around to it.

VB.net, C#, J++ and C++ with managed code are almost completly equal when
they are compiled. In this newsgroup are that the only languages which
counts and where we are talking about.

I find it an efficient way and that is what I am talking about not to make
everytime a roundtrip to the OS to clean up resources if there is enough
memory.

Look around the message
boards, people complain about memory consumption all the time, its one of
the main complaints. There have been gazillion articles on understanding the
CLR, garbage collection, and memory consumption, along with best programming
practices. Many by MS insiders and experts. Memory consumption is an issue,
there things you should and should not do.

Never seen that in this newsgroup seriously, what I have seen is that the
taskmanager shows a lot (but what is a lot) of memory consumption and that
people are afraid if the GC does work correct because it does start
immidiatly when the program closes, but I cannot be sure of that of course.

Example, when you get a .NET graphics object, it is a managed object, but
what should be the first thing you do with it when you are done with it. You
should call Dispose to release the underlying OS resources, in no way should
you let the garbage collector control the destruction of these resources,
this documented and suggested by MS themselves.

The graphics object is one of those where Microsoft explicitly advices to
dispose. When you see the start of this thread you will see that I did
mention the image as to dispose.

Cor

 

[Cor]

garbage collector does "not" start when the program .........

 

[Jon Skeet [C# MVP]]

I find it an efficient way and that is what I am talking about not to make
everytime a roundtrip to the OS to clean up resources if there is enough
memory.

That's *really* not a good idea, IMO. If something implements
IDisposable, that's a sign saying that you should call Dispose when
you're finished with it (if you're responsible for its lifetime).
Guessing as to which classes are really just taking memory and which
are taking other system resources (such as handles) is likely to cause
you problems in the future.

The graphics object is one of those where Microsoft explicitly advices to
dispose. When you see the start of this thread you will see that I did
mention the image as to dispose.

Anything which implements IDisposable is pretty much explicitly
advising you to dispose of it properly, in my view.

 

[Cor]

Hi Jon,

Anything which implements IDisposable is pretty much explicitly
advising you to dispose of it properly, in my view.

Why?

That there is VB.net does not mean that everybody is explictly advised to
use it.

Cor