Coffeehouse Thread

9 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

When to Implement IDisposable in your class?

Back to Forum: Coffeehouse
  • User profile image
    Shark_M

    Hi guys,
    I am woundering what is the advantages of using IDisposable?, do i implement it in every new class i made or even in derived classes? what is the cost of implementing IDisposable? I gather that implementing IDisposable means your declaring that there are scarce resources being utilized in the given class. So when to implement IDisposable and when not to?

    Thanks;)

  • User profile image
    Cannot​Resolve​Symbol

    I think that the big use for IDisposable is when the class needs to do some cleanup before it is destroyed, like with an I/O stream or such.  It lets you use the class inside a using() block.

  • User profile image
    ZippyV

    You only need to use the disposable interface if you have to release unmanaged objects.

  • User profile image
    RobChartier

    http://msdn.microsoft.com/library/en-us/cpref/html/frlrfSystemIDisposableClassTopic.asp

    "Defines a method to release allocated unmanaged resources."

    The garbage collector automatically releases the memory allocated to a managed object when that object is no longer used, however, it is unpredictable when garbage collection will occur. Furthermore, the garbage collector has no knowledge of unmanaged resources such as window handles, and open files and streams.

    Use the Dispose method of this interface to explicitly release unmanaged resources in conjunction with the garbage collector. The consumer of an object can call this method when the object is no longer needed.

    It is a version breaking change to add the IDisposable interface to an existing class, as it changes the semantics of the class.

    For a detailed discussion about how this interface and the Object.Finalize method are used, see the Programming for Garbage Collection and Implementing a Dispose Method topics.

  • User profile image
    Zaki

    ZippyV wrote:
    You only need to use the disposable interface if you have to release unmanaged objects.


    This is mostly true. In most applications you don't have to deal with Dispose () in explicit ways. You just let the gc do its job and everyone's happy.

    But sometimes you want to do something before the object is destroyed. Like saving some kind of information, propagating some state, or doing some custom checks, etc.

    Another case when Dispose comes handy is when you specifically want to designate a time during which you run the garbage collection. For instance if you are writing a game and you don't want to impact the game performance at times.

  • User profile image
    Shark_M

    it is unpredictable when garbage collection will occur.



    Why is that? I thought Every thing in Programming is deterministic, by the code and the programmer. Nothing has a mind of its own! So why its unpredictable when GC will occure

  • User profile image
    Zaki

    Shark_M wrote:


    Why is that? I thought Every thing in Programming is deterministic, by the code and the programmer. Nothing has a mind of its own! So why its unpredictable when GC will occure


    This is again mostly true. However you can force garbage collection if you want to. Check the System.GC object. But otherwise you cannot predict when the GC will run.

  • User profile image
    Cybermagell​an

    Zaki wrote:
    Shark_M wrote:

    Why is that? I thought Every thing in Programming is deterministic, by the code and the programmer. Nothing has a mind of its own! So why its unpredictable when GC will occure


    This is again mostly true. However you can force garbage collection if you want to. Check the System.GC object. But otherwise you cannot predict when the GC will run.


    "I THINK" if I remember correctly...that the GC runs when the application isn't using active processor time (Which who knows when that is?). That being the case I also believe that it is put in by the compiler (If I remember my C++ Books) so it doesn't even need to be called, but you can control it using the system.gc

  • User profile image
    Sven Groot

    Using the GC class to clean up vital resources is bad. The GC is pretty intelligent and unless you really know what you're doing forcing collections can actually slow your application down.

    As far as determinism goes, when the GC run depends on memory and CPU conditions that are beyond the control of the CLR itself, therefore it's not predictable when it will run. Note that it's still deterministic: if you manage to get your system in exactly the same state as before (not just your app, but everything else too, so not bloody likely) the GC will show exactly the same behaviour.

    You should implement IDisposable when you have resources to clean up after. This comes in two flavours: your class directly holds unmanaged resources, and/or your class holds members of types that implement IDisposable.

    In the latter case, you need to implement IDisposable and call Dispose on the relevant members. In this case, you do not need a finalizer (since those members have finalizers of their own so they'll take care of it) nor do you need to call GC.SuppressFinalize (although calling it doesn't hurt). In the former case, where you hold unmanaged resources, you will need both a finalizer and an IDisposable implementation. You will see in many classes in the framework (e.g. Windows Forms controls) that the Dispose pattern is implemented using a Dispose(bool) method. The finalizer calls Dispose(false) to indicate that it's finalizing, not disposing, and in response the Dispose(bool) method cleans up unmanaged resources but doesn't call Dispose on members. The IDisposable.Dispose method calls Dispose(true) which then cleans up unmanaged resources and calls any other Dispose methods needed.

    There isn't much cost involved with implementing IDisposable. At worst, a few extra calls are made (which in a CPU intensive app might make a difference, but on the whole, not too bad). Implementing a finalizer is very expensive, because the GC treats collection of types with a finalizer very different than types without one.

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.