Local variables with Delegates

Question

This ~~is clearly not~~ appears like it wouldn't be a best practice. Can someone explain why it would not be a best practice or how this works? Any books or articles providing an explanation would be appreciated.

//The constructor
public Page_Index() {

    //create a local value
    string currentValue = "This is the FIRST value";

    //use the local variable in a delegate that fires later
    this.Load += delegate(object sender, EventArgs e) {
        Response.Write(currentValue);
    };

    //change it again
    currentValue = "This is the MODIFIED value";

}

The value that is output is the second value "Modified". What part of the compiler magic is making this work? Is this as simple as keeping track of the value on the heap and retrieving it again later?

[Edit]: Given some of the comments, changing the original sentence some...

There is nothing wrong with that practice. It is just more advanced than beginners would understand. — leppie, Sep 29 '08 at 13:53
seconded; in fact, it can make for very clean / elegant design - but you do need to understand the implications. — Marc Gravell, Sep 29 '08 at 13:54
That's really quite interesting. I wouldn't think messing with local variables within the scope the delegate was assigned would be good practice, but you learn something new all the time. — hugoware, Sep 29 '08 at 14:01
It depends on the scenario; in most cases it would be a much better idea to make a second variable that is tightly scoped and never changes - but there are a few use-cases for updated captured variables, But indeed: treat them as read-only until there is a good reason and you'll have much less pain. — Marc Gravell, Sep 29 '08 at 14:05
That's the difference between a delegate and a closure. What you've made here is a closure. They are extremely powerful, and the fact that we have closures in .NET is a huge plus, not a minus. — Brad Wilson, Sep 29 '08 at 21:53

Marc Gravell · Accepted Answer · 2010-10-07T11:00:36.173

31

currentValue is no longer a local variable: it is a captured variable. This compiles to something like:

class Foo {
  public string currentValue; // yes, it is a field

  public void SomeMethod(object sender, EventArgs e) {
    Response.Write(currentValue);
  }
}
...
public Page_Index() {
  Foo foo = new Foo();
  foo.currentValue = "This is the FIRST value";
  this.Load += foo.SomeMethod;

  foo.currentValue = "This is the MODIFIED value";
}

Jon Skeet has a really good write up of this in C# in Depth, and a separate (not as detailed) discussion here.

Note that the variable currentValue is now on the heap, not the stack - this has lots of implications, not least that it can now be used by various callers.

This is different to java: in java the value of a variable is captured. In C#, the variable itself is captured.

edited Oct 07 '10 at 11:00

answered Sep 29 '08 at 13:42

Marc Gravell

1,026,079
266
2,566
2,900

As well as writing it up in C# in Depth (thanks for the plug!), I've got an article comparing C# and Java closures and explaining why they're nice: http://csharpindepth.com/Articles/Chapter5/Closures.aspx – Jon Skeet Sep 29 '08 at 13:59
Ah - as you were writing that comment, I was editing the above to include it. Double the value ;-p – Marc Gravell Sep 29 '08 at 14:02
@Mark: To slightly improve your great answer, could you exchange " variable *value* " by " *value* of the variable " in your last sentence? Since the variable is called "currentValue" it can confuse the reader (like me), first thinking that the italic " *value* " refers to the *name* of the variable (" which variable? The one called *value* ") – chiccodoro Oct 07 '10 at 08:41
1

I recommend Eric Lippert's recent blog post, about how variables stored and managed. http://blogs.msdn.com/b/ericlippert/archive/2010/09/30/the-truth-about-value-types.aspx – Prashant Cholachagudda Oct 07 '10 at 11:06

score 2 · Answer 2 · answered Sep 29 '08 at 13:52

I suppose more the question I am asking is that how is it working with a local variable [MG edit: "Ack - ignore this..." was added afterwards]

That is the point; it really isn't a local variable any more - at least, not in terms of how we normally think of them (on the stack etc). It looks like one, but it isn't.

And for info, re "not good practice" - anonymous methods and captured variables are actually an incredibly powerful tool, especially when working with events. Feel free to use them, but if you are going down this route, I would recommend picking up Jon's book to make sure you understand what is actually happening.

score 0 · Answer 3 · answered Sep 29 '08 at 13:45

0

You need to capture the value of the variable within the closure/delegate, else it can be modified, like you saw.

Assign currentValue to a variable local (inside) to the delegate.

answered Sep 29 '08 at 13:45

leppie

115,091
17
196
297

Local variables with Delegates

3 Answers3

Linked