Re: using statement equivalent - C# Discussion Boards

14-Jun-10 5:06

I've been looking around for an answer to this puzzling question, but so far no luck:

What's the compiler's try/finally equivalent of this code:

using (new SomeIDisposableClass())
{
   SomeCode();
}

Thanks!

ShamWow

Eddy Vluggen14-Jun-10 5:16

14-Jun-10 5:16

There's a CodeProject-article[^] that shows how it is translated Smile | :)

I are Troll Suspicious | :suss:

Al Beback14-Jun-10 5:24

14-Jun-10 5:24

Thanks for the quick response, but that article doesn't address my specific example where a variable is not explicitly declared inside the using statement.

ShamWow

Eddy Vluggen14-Jun-10 5:55

14-Jun-10 5:55

Al Beback wrote:
that article doesn't address my specific example where a variable is not explicitly declared inside the using statement.

Ah, my bad; it does almost the same the same thing, with the difference that you don't have a reference to your class. It still creates a class, disposing it in the finally.

public static void Main(string[] args)
{
    using (new SomeIDisposableClass())
    {
        Console.WriteLine("Hello World!");
    }
    Console.ReadKey(true);
}

..translates to..

.method public hidebysig static 
  void Main(string[] args) cil managed
{
    .entrypoint
    .maxstack 2
    .locals init (
        [0] class using_test.SomeIDisposableClass CS$3$0000,
        [1] bool CS$4$0001)
    L_0000: nop 
    L_0001: newobj instance void 
              using_test.SomeIDisposableClass::.ctor()
    L_0006: stloc.0 
    L_0007: nop 
    L_0008: ldstr "Hello World!"
    L_000d: call void [mscorlib]System.Console::WriteLine(string)
    L_0012: nop 
    L_0013: nop 
    L_0014: leave.s L_0026
    L_0016: ldloc.0 
    L_0017: ldnull 
    L_0018: ceq 
    L_001a: stloc.1 
    L_001b: ldloc.1 
    L_001c: brtrue.s L_0025
    L_001e: ldloc.0 
    L_001f: callvirt instance void 
              [mscorlib]System.IDisposable::Dispose()
    L_0024: nop 
    L_0025: endfinally 
    L_0026: nop 
    L_0027: ldc.i4.1 
    L_0028: call valuetype 
              [mscorlib]System.ConsoleKeyInfo 
              [mscorlib]System.Console::ReadKey(bool)
    L_002d: pop 
    L_002e: ret 
    .try L_0007 to L_0016 finally handler L_0016 to L_0026
}

I are Troll Suspicious | :suss:

J4amieC14-Jun-10 5:22

J4amieC

14-Jun-10 5:22

IDisposable disposable = null;
try
{
 disposable =  new SomeIDisposableClass()
 SomeCode();
}
finally
{
 disposable.Dispose();
}

Al Beback14-Jun-10 5:51

Re: using statement equivalent [modified]

14-Jun-10 5:51

Sounds logical, although I would imagine the compiler would also add an extra check for whether "disposable" is null inside the finally block.

It's interesting that none of the examples you see out there for the using statement ever mention that if you don't assign your IDisposable type to an explicitly declared variable, the compiler will do it for you behind the scenes.

Thanks.

ShamWow

dan!sh 14-Jun-10 5:46

dan!sh

14-Jun-10 5:46

Why and when would you write a code like that?

As far as its equivalent is concerned, just see the IL through ILDAsm or reflector and it would make things a bit clear. Smile | :)

modified on Monday, June 14, 2010 11:55 AM

Al Beback14-Jun-10 5:58

14-Jun-10 5:58

d@nish wrote:
Why and when would you write a code like that?

When you're interested in keeping track of when "SomeCode" begins and ends -- for logging, profiling, etc.

ShamWow

dan!sh 14-Jun-10 6:01

dan!sh

14-Jun-10 6:01

Use interceptor pattern for that. Check out Enterprise Library's Policy Injection Block to see how logging can be done before and after method call. (Search LogCallHandler)

Eddy Vluggen14-Jun-10 6:02

14-Jun-10 6:02

d@nish wrote:
Why and when would you write a code like that?

There's even a CodeProject-article[^] to answer that one! Big Grin | :-D

I are Troll Suspicious | :suss:

dan!sh 14-Jun-10 6:19

dan!sh

14-Jun-10 6:19

Nice find. Smile | :)

From now on, I am going to have this in my windows forms application (of course with proper comments):

public class AppCursor : IDisposable
    {

        Cursor _currentCursor = null;
        bool _setDefault;

        public AppCursor(Cursor cursor, bool setDefault)
        {
            _currentCursor = Cursor.Current;
            _setDefault = setDefault;
            Cursor.Current = cursor;
        }

        #region IDisposable Members

        public void Dispose()
        {
            Cursor.Current = (_setDefault) ? Cursors.Default : _currentCursor;
            
            // Even with disposing the cursor object, form works but am not sure whether it should be there or not.
            _currentCursor.Dispose();
            _currentCursor = null;
        }

        #endregion
    }

Not Active14-Jun-10 7:35

Not Active

14-Jun-10 7:35

Chris should put that in the advertising. There is an ~~app~~ article for that. Big Grin | :-D

I know the language. I've read a book. - _Madmatt

Al Beback14-Jun-10 6:04

14-Jun-10 6:04

d@nish wrote:
As far as its equivalent is concerned, just see the IL through ILDAsm or reflector and it would make things a bit clear.

I know, but shamefully, I'm IL challenged. Smile | :)

ShamWow

harold aptroot14-Jun-10 6:01

harold aptroot

14-Jun-10 6:01

Wow, everyone got it wrong Smile | :)

Debug or Release?
The debug code (bugs in Reflector corrected by looking at the MSIL)

    SomeIDisposableClass CS$3$0000;
    bool CS$4$0001;
    CS$3$0000 = new SomeIDisposableClass();
Label_0007:
    try
    {
        SomeCode();
        goto Label_0021;
    }
    finally
    {
    Label_0011:
        CS$4$0001 = CS$3$0000 == null;
        if (CS$4$0001)
        {
            goto Label_0020;
        }
        CS$3$0000.Dispose();
    Label_0020:;
    }
Label_0021:;

And yes, it is silly. It's storing the result of the null-check

The Release code

    SomeIDisposableClass CS$3$0000;
    CS$3$0000 = new SomeIDisposableClass();
Label_0006:
    try
    {
        SomeCode();
        goto Label_0017;
    }
    finally
    {
    Label_000D:
        if (CS$3$0000 == null)
        {
            goto Label_0016;
        }
        CS$3$0000.Dispose();
    Label_0016:;
    }
Label_0017:

edit: the rules for goto-within-try are
If the goto statement exits one or more try blocks with associated finally blocks, control is initially transferred to the finally block of the innermost try statement. When and if control reaches the end point of a finally block, control is transferred to the finally block of the next enclosing try statement. This process is repeated until the finally blocks of all intervening try statements have been executed.

Eddy Vluggen14-Jun-10 6:06

14-Jun-10 6:06

harold aptroot wrote:
Wow, everyone got it wrong Debug or Release?The debug code (bugs in Reflector corrected by looking at the MSIL)

Bugs?

+5 Thumbs Up | :thumbsup:

I are Troll Suspicious | :suss:

harold aptroot14-Jun-10 6:12

harold aptroot

14-Jun-10 6:12

Bugs like this one.. if ((CS$3$0000 == null) != null)
That's not even possible, and the IL for that part is just

MSIL

L_0011: ldloc.0
L_0012: ldnull
L_0013: ceq
L_0015: stloc.1
L_0016: ldloc.1
L_0017: brtrue.s L_0020

So Mr Reflector just skipped over a load/store and made up a comparison WTF | :WTF:

Al Beback14-Jun-10 6:18