<

Want to win a PS4? Go Premium and enter to win our High-Tech Treats giveaway. Enter to Win

x

Using IDisposable Part 1: How to use IDisposable objects

Published on
10,972 Points
4,272 Views
2 Endorsements
Last Modified:
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
Comment
Author:zadeveloper
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
1 Comment
 
LVL 75

Expert Comment

by:käµfm³d 👽
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.
0

Featured Post

Free Tool: Subnet Calculator

The subnet calculator helps you design networks by taking an IP address and network mask and returning information such as network, broadcast address, and host range.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

Join & Write a Comment

This course is ideal for IT System Administrators working with VMware vSphere and its associated products in their company infrastructure. This course teaches you how to install and maintain this virtualization technology to store data, prevent vuln…
Are you ready to place your question in front of subject-matter experts for more timely responses? With the release of Priority Question, Premium Members, Team Accounts and Qualified Experts can now identify the emergent level of their issue, signal…

Keep in touch with Experts Exchange

Tech news and trends delivered to your inbox every month