.NET IL Property setter

Question

Consider this class:

public class Foo
{
    // Fields
    private string _bar;

    // Properties
    private string Bar
    {
        get
        {
            return this._bar;
        }
        set
        {
            this._bar = value;
        }
    }
}

Now when I go and look in the IL code emitted by the compiler for the setter of the Bar property:

.method private hidebysig specialname instance void set_Bar(string 'value') cil managed
{
    .maxstack 8
    L_0000: nop 
    L_0001: ldarg.0 
    L_0002: ldarg.1 
    L_0003: stfld string ConsoleApplication2.Program/Foo::_bar
    L_0008: ret 
}

Why does it do a ldarg.0 ? WHAT is located in first (index 0) argument? Since the method/property setter only takes 1 argument...

The same goes for the getter:

.method private hidebysig specialname instance string get_Bar() cil managed
{
    .maxstack 1
    .locals init (
        [0] string CS$1$0000)
    L_0000: nop 
    L_0001: ldarg.0 
    L_0002: ldfld string ConsoleApplication2.Program/Foo::_bar
    L_0007: stloc.0 
    L_0008: br.s L_000a
    L_000a: ldloc.0 
    L_000b: ret 
}

Why the .locals init ? Why the ldarg.0 ? Why doesn't it do a ldfld of the backing field and just return that? :)

score 4 · Accepted Answer · answered Nov 15 '10 at 13:23

4

For the setter:

Any instance member has an implicit "this" parameter - that's what's being loaded, basically. Try turning it into a static property and you'll see it go away.

For the getter, I'm not sure why there's the local variable... debugger support perhaps? Certainly compiling it in optimized mode (/o+ /debug- from the command line) gets rid of the local variable.

answered Nov 15 '10 at 13:23

Jon Skeet

1,421,763
867
9,128
9,194

But why push it onto the stack? Seems like a waste of space to me. – Anemoia Nov 15 '10 at 13:25
@Snake: Don't forget that you're looking at the IL, not the final native code. Just because IL represents "getting a field from a particular instance" by pushing something onto the stack doesn't mean that's what really happens. – Jon Skeet Nov 15 '10 at 13:27
@Snake: Stack as in the evaluation stack, not stack memory vs heap memory. ldfld will load a field but it needs an instance of the class to do so. There is no implicit this, ergo the ldarg.0 http://msdn.microsoft.com/en-us/library/system.reflection.emit.opcodes.ldfld.aspx The rest of the inefficiency just looks like extra instructions left in by debug. – Krypes Nov 15 '10 at 13:36

.NET IL Property setter

1 Answers1