C# in Depth

158 CHAPTER 5 Fast-tracked delegatesHow long would it take you to predict the output from listing 5.14 (even with theannotations)? Frankly it would take me a little while—longer than I like to spendunderstanding code. Just as an exercise, though, let’s look at what happens.First let’s consider the outside variable B. The scope it’s declared in is only enteredonce, so it’s a straightforward case—there’s only ever one of it, effectively. The insidevariable C is a different matter—each loop iteration instantiates a new one. Thatmeans that when we create the delegate instance D the outside variable is sharedbetween the two delegate instances, but each of them has its own inside variable.After the loop has ended, we call the first delegate instance we created three times.Because it’s incrementing both of its captured variables each time, and we started offwith them both as 0, we see (0,0), then (1,1), then (2,2). The difference between thetwo variables in terms of scope becomes apparent when we execute the second delegateinstance. It has a different inside variable, so that still has its initial value of 0,but the outside variable is the one we’ve already incremented three times. The outputfrom calling the second delegate twice is therefore (3,0), then (4,1).NOTE How does this happen internally? Just for the sake of interest, let’s thinkabout how this is implemented—at least with Microsoft’s C# 2 compiler.What happens is that one extra class is generated to hold the outer variable,and another one is generated to hold an inner variable and a referenceto the first extra class. Essentially, each scope that contains a capturedvariable gets its own type, with a reference to the next scope out that containsa captured variable. In our case, there were two instances of the typeholding inner, and they both refer to the same instance of the type holdingouter. Other implementations may vary, but this is the most obviousway of doing things.Even after you understand this code fully, it’s still quite a good template for experimentingwith other elements of captured variables. As we noted earlier, certain elementsof variable capture are implementation specific, and it’s often useful to refer tothe specification to see what’s guaranteed—but it’s also important to be able to justplay with code to see what happens.It’s possible that there are situations where code like listing 5.14 would be the simplestand clearest way of expressing the desired behavior—but I’d have to see it to believeit, and I’d certainly want comments in the code to explain what would happen. So, whenis it appropriate to use captured variables, and what do you need to look out for?5.5.7 Captured variable guidelines and summaryHopefully this section has convinced you to be very careful with captured variables.They make good logical sense (and any change to make them simpler would probablyeither make them less useful or less logical), but they make it quite easy to producehorribly complicated code.Don’t let that discourage you from using them sensibly, though—they can save youmasses of tedious code, and when they’re used appropriately they can be the mostreadable way of getting the job done. But what counts as “sensible”?Licensed to Rhona Hadida