Valid Reason for Using IDisposable intreface
-
As you pointed out yourself, it makes sense to implement IDisposable to free up unmanaged resources. Since this class embeds an Image, which is IDisposable, it should itself be disposable. I didn't read all of the lenghty unformatted code you posted, but if that's all there is to it, it would suffice to do this:
public void Dispose()
{
if (img != null) img.Dispose();
}Thats fine. There is nothing relevant in my code. Code i have given just for explaining my Problem. So Can u please tell me why should i inherit my class from IDisposable intreface for implementing dispose method? Here i can write my own Dispose method without inheriting IDisposable intreface which i have shown in my code. Then can u please tell me why microsoft is telling that i have to inherit my class from IDisposable intreface for implimenting dispose method? is there any specific reason behind that? in my code directly i used img.Dispose();. here i no need to inherit my class from IDisposable intreface. I think u can understand what i am trying to clarify.. Regards Lijo
-
Thats fine. There is nothing relevant in my code. Code i have given just for explaining my Problem. So Can u please tell me why should i inherit my class from IDisposable intreface for implementing dispose method? Here i can write my own Dispose method without inheriting IDisposable intreface which i have shown in my code. Then can u please tell me why microsoft is telling that i have to inherit my class from IDisposable intreface for implimenting dispose method? is there any specific reason behind that? in my code directly i used img.Dispose();. here i no need to inherit my class from IDisposable intreface. I think u can understand what i am trying to clarify.. Regards Lijo
Once i used interface for a plugin. If you use unmanaged calss, you need to close window handles and other stuff. The IDisposable interface exsist for GarbageColletor that can properly dispose a class. This apply to automatic Dispose. Not call from a code
-
Once i used interface for a plugin. If you use unmanaged calss, you need to close window handles and other stuff. The IDisposable interface exsist for GarbageColletor that can properly dispose a class. This apply to automatic Dispose. Not call from a code
I think u guys did not understand my question. i very well know tat we have to use IDisposable intreface for handiling un managed resources. but we no need to inherit our class from IDisposable intreface for implimenting Dispose method. I can write my own Dispose method. So my question is what is the specific reason behind inheriting our class from IDisposable intreface?
-
I think u guys did not understand my question. i very well know tat we have to use IDisposable intreface for handiling un managed resources. but we no need to inherit our class from IDisposable intreface for implimenting Dispose method. I can write my own Dispose method. So my question is what is the specific reason behind inheriting our class from IDisposable intreface?
This is from MSDN: The primary use of this interface is to release unmanaged resources. The garbage collector automatically releases the memory allocated to a managed object when that object is no longer used. However, it is not possible to predict when garbage collection will occur. Furthermore, the garbage collector has no knowledge of unmanaged resources such as window handles, or open files and streams. In other words if you implement your own Dispose without implementing IDisposable interface, Garbage collector won't be able to call Dispose method. If you call manualy Dispose method it does not hurt system. If you do not implement IDisposable iterface and you do not call Dispose method, Garbage Collector will not call Dispose, so any unmanaged handles will remain even after the process was closed or killed. I suggest you Implement it, because it doesn't hurt to have it
-
Hi All, Can anyone please clarify my dout about IDisposable intreface in C#. We all know tat IDisposable interface is using for disposing unmanaged resources. I have a class which contains following code. here i have implimented the Dispose method from IDisposable interface. class ClassA:IDisposable { public ClassA() { Console.WriteLine("ClassBeingTested: Constructor"); } private bool disposed = false; Image img = null; public Image Image { get { return img; } } ~ClassA() { Console.WriteLine("ClassBeingTested: Destructor"); // call Dispose with false. Since we're in the // destructor call, the managed resources will be // disposed of anyways. Dispose(false); } public void Dispose() { Console.WriteLine("ClassBeingTested: Dispose"); // dispose of the managed and unmanaged resources Dispose(true); // tell the GC that the Finalize process no longer needs // to be run for this object. GC.SuppressFinalize(this); } protected virtual void Dispose(bool disposeManagedResources) { // process only if mananged and unmanaged resources have // not been disposed of. if (!this.disposed) { Console.WriteLine("ClassBeingTested: Resources not disposed"); if (disposeManagedResources) { Console.WriteLine("ClassBeingTested: Disposing managed resources"); // dispose managed resources if (img != null) { img.Dispose(); img = null; } } // dispose unmanaged resources Console.WriteLine("ClassBeingTested: Disposing unmanaged resouces"); disposed = true; } else { Console.WriteLine("ClassBeingTested: Resources already disposed"); } } // loading an image public void LoadImage(string file) { Console.WriteLine("ClassBeingTested: LoadImage"); img = Image.FromFile(file); } } What my doubt is why i need to impliment the Dispose method from IDisposable interface?. Instead of that i can create my own Dispose method in my class without inheriting from IDisposable interface which i have given below. for the class below i haven't inherited my class from IDisposable interface. instead of that i created my own dispose method. this also works fine. class ClassA { public ClassA() { Console.WriteLine("ClassBeingTested: Constructor"); } private bool disposed = false; Image img = null; public Image Image { get { return img; } } ~ClassA() { Console.WriteLine("ClassBeingTested: Destructor"); // call Dispose with false. Since we're in the // destructor call, the managed resources will be // disposed of anyways. Dispose(false); } pub
If you did not implement from
IDisposable, you wouldn't be able to use theusingconstruct to automatically dispose your object - you'd have to take care of it yourself. Effectively, theusingconstruct turns the code into a try/finally block whereDisposeis called in the finally portion - it uses a cast toIDisposableto ensure that it can do this. Consider the following sample:public class MyBaseClass
{
// Some stuff in here.
public virtual void Dispose()
{}
}
public class MyDisposableBaseClass : MyBaseClass, IDisposable
{
// No need to implement the Dispose method here because this
// class derives from a class that already has a Dispose, method
// even though that class doesn't implement IDisposable.
}
// some code, which then gets called as:
using (MyBaseClass myClass = new MyDisposableBaseClass())
{
// There's a problem, and this won't compile because MyBaseClass does not
// implement IDisposable.
}
// Change the code to
using (MyDisposableBaseClass myClass = new MyDisposableBaseClass())
{
// The code gets disposed automatically.
}As you can see, even though
MyBaseClasshas aDisposemethod, you can't use it in ausingblock for disposal."WPF has many lovers. It's a veritable porn star!" - Josh Smith
As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
-
Hi All, Can anyone please clarify my dout about IDisposable intreface in C#. We all know tat IDisposable interface is using for disposing unmanaged resources. I have a class which contains following code. here i have implimented the Dispose method from IDisposable interface. class ClassA:IDisposable { public ClassA() { Console.WriteLine("ClassBeingTested: Constructor"); } private bool disposed = false; Image img = null; public Image Image { get { return img; } } ~ClassA() { Console.WriteLine("ClassBeingTested: Destructor"); // call Dispose with false. Since we're in the // destructor call, the managed resources will be // disposed of anyways. Dispose(false); } public void Dispose() { Console.WriteLine("ClassBeingTested: Dispose"); // dispose of the managed and unmanaged resources Dispose(true); // tell the GC that the Finalize process no longer needs // to be run for this object. GC.SuppressFinalize(this); } protected virtual void Dispose(bool disposeManagedResources) { // process only if mananged and unmanaged resources have // not been disposed of. if (!this.disposed) { Console.WriteLine("ClassBeingTested: Resources not disposed"); if (disposeManagedResources) { Console.WriteLine("ClassBeingTested: Disposing managed resources"); // dispose managed resources if (img != null) { img.Dispose(); img = null; } } // dispose unmanaged resources Console.WriteLine("ClassBeingTested: Disposing unmanaged resouces"); disposed = true; } else { Console.WriteLine("ClassBeingTested: Resources already disposed"); } } // loading an image public void LoadImage(string file) { Console.WriteLine("ClassBeingTested: LoadImage"); img = Image.FromFile(file); } } What my doubt is why i need to impliment the Dispose method from IDisposable interface?. Instead of that i can create my own Dispose method in my class without inheriting from IDisposable interface which i have given below. for the class below i haven't inherited my class from IDisposable interface. instead of that i created my own dispose method. this also works fine. class ClassA { public ClassA() { Console.WriteLine("ClassBeingTested: Constructor"); } private bool disposed = false; Image img = null; public Image Image { get { return img; } } ~ClassA() { Console.WriteLine("ClassBeingTested: Destructor"); // call Dispose with false. Since we're in the // destructor call, the managed resources will be // disposed of anyways. Dispose(false); } pub
Along with what Pete said in the above reply about the
usingconstruct, implementing IDisposable helps automatic tools detect potential memory leaks. In your example, your class contains a disposable object. If the dispose method on your class never gets called, the image will not be disposed and the unmanaged resource will leak. When you implement IDisposable, tools have a better chance of detecting such leaks. As an aside, you should not have a class finalizer (the ~A()) method unless you directly own an unmanaged resource such as a file handle stored as an IntPtr. The IDisposable classes you own as fields will have their own finalizer to take care of the unmanaged resources. Having unnecessary finalizers decreases the efficiency of the garbage collector. -
Along with what Pete said in the above reply about the
usingconstruct, implementing IDisposable helps automatic tools detect potential memory leaks. In your example, your class contains a disposable object. If the dispose method on your class never gets called, the image will not be disposed and the unmanaged resource will leak. When you implement IDisposable, tools have a better chance of detecting such leaks. As an aside, you should not have a class finalizer (the ~A()) method unless you directly own an unmanaged resource such as a file handle stored as an IntPtr. The IDisposable classes you own as fields will have their own finalizer to take care of the unmanaged resources. Having unnecessary finalizers decreases the efficiency of the garbage collector.Gideon Engelberth wrote:
As an aside, you should not have a class finalizer (the ~A()) method unless you directly own an unmanaged resource such as a file handle stored as an IntPtr. The IDisposable classes you own as fields will have their own finalizer to take care of the unmanaged resources. Having unnecessary finalizers decreases the efficiency of the garbage collector.
I agree mainly as it is a valid information, but he get's around this problem, as he is using:
GC.SuppressFinalize(this);
By calling the "SuppressFinalize", the GC will not move the object to the finalization queue, and so prefent the double lookup of the object.
All the best, Martin
-
Thats fine. There is nothing relevant in my code. Code i have given just for explaining my Problem. So Can u please tell me why should i inherit my class from IDisposable intreface for implementing dispose method? Here i can write my own Dispose method without inheriting IDisposable intreface which i have shown in my code. Then can u please tell me why microsoft is telling that i have to inherit my class from IDisposable intreface for implimenting dispose method? is there any specific reason behind that? in my code directly i used img.Dispose();. here i no need to inherit my class from IDisposable intreface. I think u can understand what i am trying to clarify.. Regards Lijo
Sorry for the delay in responding - I forgot about it. 1) It tells the user of the class that instances should be disposed. A programmer familiar with .NET will immediately recognize and understand what pattern is involved and the reasons for it just by glancing at the class declaration. 2) It allows code to test programmatically if an object is disposable and to invoke the logic without knowledge of it's type.
if (obj is IDisposable) ((IDisposable)obj).Dispose();3) It allows encapsulation of the object's resources. In your case, and in many cases, you may need to expose the image to outside users (rather than clone the internal resource and return a copy). But in general, a class should be responsible for managing all the state belonging to it. Following this guideline greatly simplifies life even if you cannot always *enforce* it by fully encapsulating state. 4) It allows the user to easily ensure instances are in fact disposed, whether or not exceptions occur, since several CLS-compliant languages (including C# and VB.NET) have special statements for this exact purpose. In C#,using (var x = new MyThing()) // MyThing is IDisposable
{
... code block ...
}// is equivalent to
var x = new MyThing();
try
{
... code block ...
}
finally
{
if (x != null) x.Dispose();
}All of these are, in my opinion, important reasons for implementing IDisposable when the object is in fact disposable. Having
x.img.Dispose()violates established OOP practice (and there are good reasons for that practice). -
Gideon Engelberth wrote:
As an aside, you should not have a class finalizer (the ~A()) method unless you directly own an unmanaged resource such as a file handle stored as an IntPtr. The IDisposable classes you own as fields will have their own finalizer to take care of the unmanaged resources. Having unnecessary finalizers decreases the efficiency of the garbage collector.
I agree mainly as it is a valid information, but he get's around this problem, as he is using:
GC.SuppressFinalize(this);
By calling the "SuppressFinalize", the GC will not move the object to the finalization queue, and so prefent the double lookup of the object.
All the best, Martin
He does, but only when the user has called Dispose. And since the class didn't implement IDisposable there is a higher probability that objects would not have been disposed. (At least where I've worked there tend to be plenty of programmers who fail to include try-finally blocks where necessary for correctness, as they (I believe) work based on the idea that if it runs OK on their machine this means the code is "correct" - a notion it would be useful to disspell from our profession imho.)
-
He does, but only when the user has called Dispose. And since the class didn't implement IDisposable there is a higher probability that objects would not have been disposed. (At least where I've worked there tend to be plenty of programmers who fail to include try-finally blocks where necessary for correctness, as they (I believe) work based on the idea that if it runs OK on their machine this means the code is "correct" - a notion it would be useful to disspell from our profession imho.)
dojohansen wrote:
And since the class didn't implement IDisposable there is a higher probability that objects would not have been disposed.
Second that! I wouldn't like to see such an implementation in my projects as it makes no sence not to implement IDisposable. I just wanted to point to the "SuppressFinalize", also for the cases were you have to worry about your unmanaged recources.
All the best, Martin
-
He does, but only when the user has called Dispose. And since the class didn't implement IDisposable there is a higher probability that objects would not have been disposed. (At least where I've worked there tend to be plenty of programmers who fail to include try-finally blocks where necessary for correctness, as they (I believe) work based on the idea that if it runs OK on their machine this means the code is "correct" - a notion it would be useful to disspell from our profession imho.)
That's the main hit, but there is still a small hit from the fact that it has to be put on the finalization list in the first place (and then taken back off in Dispose). I have no idea how big that hit is, since that will depend mostly on how many of these objects are being created.