C# in Depth

Capturing variables in anonymous methods155ret();return ret;}...ThreadStart x = CreateDelegateInstance();x();x();The output of listing 5.12 consists of the numbers 5, 6, and 7 on separate lines. Thefirst line of output comes from the invocation of the delegate instance withinCreateDelegateInstance, so it makes sense that the value of i is available at thatpoint. But what about after the method has returned? Normally we would considercounter to be on the stack, so when the stack frame for CreateDelegateInstance isdestroyed we’d expect counter to effectively vanish… and yet subsequent invocationsof the returned delegate instance seem to keep using it!The secret is to challenge the assumption that counter is on the stack in the firstplace. It isn’t. The compiler has actually created an extra class to hold the variable.The CreateDelegateInstance method has a reference to an instance of that class so itcan use counter, and the delegate has a reference to the same instance—which liveson the heap in the normal way. That instance isn’t eligible for garbage collection untilthe delegate is ready to be collected. Some aspects of anonymous methods are verycompiler specific (in other words different compilers could achieve the same semanticsin different ways), but it’s hard to see how the specified behavior could beachieved without using an extra class to hold the captured variable. Note that if youonly capture this, no extra types are required—the compiler just creates an instancemethod to act as the delegate’s action.OK, so local variables aren’t always local anymore. You may well be wondering whatI could possibly throw at you next—let’s see now, how about multiple delegates capturingdifferent instances of the same variable? It sounds crazy, so it’s just the kind ofthing you should be expecting by now.5.5.5 Local variable instantiationsOn a good day, captured variables act exactly the way I expect them to at a glance. Ona bad day, I’m still surprised when I’m not taking a great deal of care. When there areproblems, it’s almost always due to forgetting just how many “instances” of local variablesI’m actually creating. A local variable is said to be instantiated each time executionenters the scope where it’s declared. Here’s a simple example comparing two verysimilar bits of code:int single;for (int i=0; i < 10; i++){single = 5;Console.WriteLine(single+i);}for (int i=0; i < 10; i++){int multiple = 5;Console.WriteLine(multiple+i);}Licensed to Rhona Hadida