StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>A couple of points:</p> <p>Calling <code>Dispose</code> does not increase performance. <code>IDisposable</code> is designed for scenarios where you are using limited and/or unmanaged resources that cannot be accounted for by the runtime.</p> <p>There is no clear and obvious mechanism as to how the compiler could treat <code>IDisposable</code> objects in the code. What makes it a candidate for being disposed of automatically and what doesn't? If the instance is (or could) be exposed outside of the method? There's nothing to say that just because I pass an object to another function or class that I want it to be usable beyond the scope of the method </p> <p>Consider, for example, a factory patter that takes a <code>Stream</code> and deserializes an instance of a class.</p> <pre><code>public class Foo { public static Foo FromStream(System.IO.Stream stream) { ... } } </code></pre> <p>And I call it:</p> <pre><code>Stream stream = new FileStream(path); Foo foo = Foo.FromStream(stream); </code></pre> <p>Now, I may or may not want that <code>Stream</code> to be disposed of when the method exits. If <code>Foo</code>'s factory reads all of the necessary data from the <code>Stream</code> and no longer needs it, then I would want it to be disposed of. If the <code>Foo</code> object has to hold on to the stream and use it over its lifetime, then I wouldn't want it to be disposed of. </p> <p>Likewise, what about instances that are retrieved from something other than a constructor, like <code>Control.CreateGraphics()</code>. These instances <em>could</em> exist outside of the code, so the compiler wouldn't dispose of them automatically. </p> <p>Giving the user control (and providing an idiom like the <code>using</code> block) makes the user's intention clear and makes it much easier to spot places where <code>IDisposable</code> instances are not being properly disposed of. If the compiler were to automatically dispose of <em>some</em> instances, then debugging would be that much more difficult as the developer had to decipher how the automatic disposal rules applied to each and every block of code that used an <code>IDisposable</code> object.</p> <p>In the end, there are two reasons (by convention) for implementing <code>IDisposable</code> on a type.</p> <ol> <li>You are using an unmanaged resource (meaning you're making a P/Invoke call that returns something like a handle that must be released by a different P/Invoke call)</li> <li>Your type has instances of <code>IDisposable</code> that should be disposed of when this object's lifetime is over.</li> </ol> <p>In the first case, all such types are supposed to implement a finalizer that calls <code>Dispose</code> and releases all <em>unmanaged</em> resources if the developer fails to do so (this is to prevent memory and handle leaks).</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload