Community Pick: Many members of our community have endorsed this article.

Using IDisposable Part 1: How to use IDisposable objects

JarrodDeveloper of Stuff
Published:
Introduction

This article series is supposed to shed some light on the use of IDisposable and objects that inherit from it. In essence, a more apt title for this article would be: using (IDisposable) {}. I’m just not sure how many people would get that off the bat and you are one of them you should understand by the end of the Part 1.  Part 2 will deal with creating objects and inheriting from IDisposable.

With wonderful things like disposable objects and garbage collection I feel most of our developer colleagues have forgotten about memory management and memory leaks. If you are one of those people who would say: “There is so much memory available these days we don’t need to worry about memory”, then you fall into 1 of 2 categories.

You have not developed anything more complex than a “hello world” app
You are a VB developer
Either way you don’t need to continue reading. (This article is meant for developers) ?

Before getting into the article consider the following priorities when developing:
Code must execute as fast as possible (yes I mean shaving off 1/(1 000 000) of a millisecond)
The application must be as small as possible (no useless processor executions)

How to use an object of type IDisposable

Let’s assume that you want to open a connection to Sql Server. There are 2 ways to do this with executing the .Dispose() method. By the way – you have to call .Dispose() on a disposable object to free it from memory. Don’t leave this takes to the garbage collector, as you know they don’t make much cash and often don’t do their job properly. For example if I write a class and don’t call dispose from my destructor – when the variable is out of scope and the destructor is called IDispose might not be – depending how good a developer I am. Let’s look at these functions:
       
public void TestA()
                              {
                                  using (var cn = new SqlConnection("Some String A"))
                                  {
                                      cn.Open();
                                  }
                              }

Open in new window

...and...
 public void TestB()
                              {
                                  var cn = new SqlConnection("Some String B");
                                  cn.Open();
                                  cn.Dispose();
                              }

Open in new window

Now, for some of you, this may come as a shock to see the using keyword used anywhere else but the top of your source code file. Actually what it is doing is declaring a block between {} where the object defined in the () can be used (and by the way the object has to inherit from IDisposable). Once the code leaves the block the .Dispose() method is called on the object weather it leaves gracefully or via an exception being thrown. The object then becomes out of scope.  Let’s have a look at the IL code that is created for these 2 functions.
.method public hidebysig instance void TestA() cil managed
                      {
                          .maxstack 2
                          .locals init (
                              [0] class [System.Data]System.Data.SqlClient.SqlConnection cn,
                              [1] bool CS$4$0000)
                          L_0000: nop 
                          L_0001: ldstr "Some String A"
                          L_0006: newobj instance void [System.Data]System.Data.SqlClient.SqlConnection::.ctor(string)
                          L_000b: stloc.0 
                          L_000c: nop 
                          L_000d: ldloc.0 
                          L_000e: callvirt instance void [System.Data]System.Data.Common.DbConnection::Open()
                          L_0013: nop 
                          L_0014: nop 
                          L_0015: leave.s L_0027
                          L_0017: ldloc.0 
                          L_0018: ldnull 
                          L_0019: ceq 
                          L_001b: stloc.1 
                          L_001c: ldloc.1 
                          L_001d: brtrue.s L_0026
                          L_001f: ldloc.0 
                          L_0020: callvirt instance void [mscorlib]System.IDisposable::Dispose()
                          L_0025: nop 
                          L_0026: endfinally 
                          L_0027: nop 
                          L_0028: ret 
                          .try L_000c to L_0017 finally handler L_0017 to L_0027
                      }

Open in new window


.method public hidebysig instance void TestB() cil managed
                      {
                          .maxstack 2
                          .locals init (
                              [0] class [System.Data]System.Data.SqlClient.SqlConnection cn)
                          L_0000: nop 
                          L_0001: ldstr "Some String B"
                          L_0006: newobj instance void [System.Data]System.Data.SqlClient.SqlConnection::.ctor(string)
                          L_000b: stloc.0 
                          L_000c: ldloc.0 
                          L_000d: callvirt instance void [System.Data]System.Data.Common.DbConnection::Open()
                          L_0012: nop 
                          L_0013: ldloc.0 
                          L_0014: callvirt instance void [System]System.ComponentModel.Component::Dispose()
                          L_0019: nop 
                          L_001a: ret 
                      }

Open in new window


As you can see TestA creates more execution code than TestB and they do exactly the same thing, violating our “small as possible” rule. Exactly? Well no … not exactly. You see, if an exception is thrown at let’s say: Open(): TestB will not execute the .Dispose() method, while TestA will. So we need to modify TestB to become TestC to become more like TestA. It looks like this:
public void TestC()
                              {
                                  SqlConnection cn = null;
                                  try
                                  {
                                      cn = new SqlConnection("Some String C");
                                      cn.Open();
                                  }
                                  finally 
                                  {
                                      cn.Dispose();
                                  }
                              }

Open in new window

.method public hidebysig instance void TestC() cil managed
                      {
                          .maxstack 2
                          .locals init (
                              [0] class [System.Data]System.Data.SqlClient.SqlConnection cn)
                          L_0000: nop 
                          L_0001: ldnull 
                          L_0002: stloc.0 
                          L_0003: nop 
                          L_0004: ldstr "Some String C"
                          L_0009: newobj instance void [System.Data]System.Data.SqlClient.SqlConnection::.ctor(string)
                          L_000e: stloc.0 
                          L_000f: ldloc.0 
                          L_0010: callvirt instance void [System.Data]System.Data.Common.DbConnection::Open()
                          L_0015: nop 
                          L_0016: nop 
                          L_0017: leave.s L_0023
                          L_0019: nop 
                          L_001a: ldloc.0 
                          L_001b: callvirt instance void [System]System.ComponentModel.Component::Dispose()
                          L_0020: nop 
                          L_0021: nop 
                          L_0022: endfinally 
                          L_0023: nop 
                          L_0024: ret 
                          .try L_0003 to L_0019 finally handler L_0019 to L_0023
                      }

Open in new window


Well, that looks very close to the IL code for TestA and it does the same thing. In fact TestA has this extra:
It declares and uses an extra boolean value. So comparing TestA and TestC, removing all the non-executing lines we have TestA producing 23 executable lines and TestC producing 21 executable lines.
So TestC wins when it comes to executing speed (by 2 executions) and TestA wins the “neat code” award.  Bearing in mind that you probably have a try… catch anyway, TestC is the best way to go.

Just for giggles, let’s see what happens if you put a try finally (I know you should have a try catch there anyway) around using in TestA (which is possibly the case anyway).
public void TestA2()
                              {
                                  try
                                  {
                                      using (var cn = new SqlConnection("Some String A"))
                                      {
                                          cn.Open();
                                      }
                                  }
                                  finally
                                  {
                                    //do stuff
                                  }            
                              }

Open in new window

...and...
.method public hidebysig instance void TestA2() cil managed
                      {
                          .maxstack 2
                          .locals init (
                              [0] class [System.Data]System.Data.SqlClient.SqlConnection cn,
                              [1] bool CS$4$0000)
                          L_0000: nop 
                          L_0001: nop 
                          L_0002: ldstr "Some String A"
                          L_0007: newobj instance void [System.Data]System.Data.SqlClient.SqlConnection::.ctor(string)
                          L_000c: stloc.0 
                          L_000d: nop 
                          L_000e: ldloc.0 
                          L_000f: callvirt instance void [System.Data]System.Data.Common.DbConnection::Open()
                          L_0014: nop 
                          L_0015: nop 
                          L_0016: leave.s L_0028
                          L_0018: ldloc.0 
                          L_0019: ldnull 
                          L_001a: ceq 
                          L_001c: stloc.1 
                          L_001d: ldloc.1 
                          L_001e: brtrue.s L_0027
                          L_0020: ldloc.0 
                          L_0021: callvirt instance void [mscorlib]System.IDisposable::Dispose()
                          L_0026: nop 
                          L_0027: endfinally 
                          L_0028: nop 
                          L_0029: nop 
                          L_002a: leave.s L_002f
                          L_002c: nop 
                          L_002d: nop 
                          L_002e: endfinally 
                          L_002f: nop 
                          L_0030: ret 
                          .try L_000d to L_0018 finally handler L_0018 to L_0028
                          .try L_0001 to L_002c finally handler L_002c to L_002f
                      }

Open in new window


Well, the IL code size skyrockets!

Pros for using the “using” word:
Neat readable code
Less C# code for the human to write
No chance of the object not disposing

Pros for manually putting in the graft to think things though:
More C# Code
Smaller and faster app (we are talking nanoseconds)

So I guess you will have to draw your own conclusions here. In part 2 we will discuss creating our own objects which implement IDisposable, and why and when we should do that.

This article was originally posted at www.zadeveloper.com
2
5,098 Views
JarrodDeveloper of Stuff

Comments (1)

CERTIFIED EXPERT
Most Valuable Expert 2011
Top Expert 2015

Commented:
You are a VB developer
Not sure why VB developers are being singled out here. IDisposable is a .NET concept, not a C# or VB concept. It exists in both languages (even C++.NET and F# have it), and its intent is the same. Speaking of which...

...you have to call .Dispose() on a disposable object to free it from memory.
The intent of Dispose is not to release the object being disposed from memory. Its intent is for the programmer to trigger the object to release any unmanaged resources that the object may be holding on to. IDisposable has no bearing over when the object itself will be purged from memory by the GC. The GC itself has no knowledge of unmanaged resources, which is why Dispose exists. Dispose is for the programmer to explicitly trigger the release of unmanaged resources; Finalize (what you referred to as a "destructor") is an implicit trigger of the same.

With regard to using statements, there are actually times when a using is counter-productive--though, most times it is advisable to use a using.

Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.