13.07.2015 Views

C# in Depth

C# in Depth

C# in Depth

SHOW MORE
SHOW LESS
  • No tags were found...

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

154 CHAPTER 5 Fast-tracked delegatesvariables were around, it wouldn’t have made much sense for List.F<strong>in</strong>dAll toexist, because of all the hoops you’d have to go through <strong>in</strong> order to create the rightdelegate to start with. It would have been simpler to do all the iteration and copy<strong>in</strong>gmanually. With <strong>C#</strong> 2, however, we can do it all very, very easily:List F<strong>in</strong>dAllYoungerThan(List people, <strong>in</strong>t limit){return people.F<strong>in</strong>dAll (delegate (Person person){ return person.Age < limit; });}Here we’re captur<strong>in</strong>g the limit parameter with<strong>in</strong> the delegate <strong>in</strong>stance—if we’d hadanonymous methods but not captured variables, we could have performed a test aga<strong>in</strong>sta hard-coded limit, but not one that was passed <strong>in</strong>to the method as a parameter. I hopeyou’ll agree that this approach is very neat—it expresses exactly what we want to do withmuch less fuss about exactly how it should happen than you’d have seen <strong>in</strong> a <strong>C#</strong> 1 version.(It’s even neater <strong>in</strong> <strong>C#</strong> 3, admittedly… 7 ) It’s relatively rare that you come across a situationwhere you need to write to a captured variable, but aga<strong>in</strong> that can certa<strong>in</strong>ly haveits uses.Still with me? Good. So far, we’ve only used the delegate <strong>in</strong>stance with<strong>in</strong> the methodthat creates it. That doesn’t raise many questions about the lifetime of the captured variables—butwhat would happen if the delegate <strong>in</strong>stance escaped <strong>in</strong>to the big bad world?How would it cope after the method that created it had f<strong>in</strong>ished?5.5.4 The extended lifetime of captured variablesThe simplest way of tackl<strong>in</strong>g this topic is to state a rule, give an example, and thenth<strong>in</strong>k about what would happen if the rule weren’t <strong>in</strong> place. Here we go:A captured variable lives for at least as long as any delegate <strong>in</strong>stancereferr<strong>in</strong>g to it.Don’t worry if it doesn’t make a lot of sense yet—that’s what the example is for. List<strong>in</strong>g5.12 shows a method that returns a delegate <strong>in</strong>stance. That delegate <strong>in</strong>stance is createdus<strong>in</strong>g an anonymous method that captures an outer variable. So, what will happenwhen the delegate is <strong>in</strong>voked after the method has returned?List<strong>in</strong>g 5.12Demonstration of a captured variable hav<strong>in</strong>g its lifetime extendedstatic ThreadStart CreateDelegateInstance(){<strong>in</strong>t counter = 5;ThreadStart ret = delegate{Console.WriteL<strong>in</strong>e(counter);counter++;};7In case you’re wonder<strong>in</strong>g: return people.Where(person => person.Age < limit);Licensed to Rhona Hadida

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!