Submitted by BillB on 12/9/2009

(If you have a minute, please add a comment when you're done so I know if I'm presenting this well enough.)

C# Delegates and Lambdas

Contents

• Delegates are Used as Callback Arguments
• Delegates in C# 1.0
• C# 2.0
• Anonymous Methods
• Lambdas
• MulticastDelegate
• Play Time
• Real World .Net Example : List<T>.FindIndex
• Linq

Delegates are Used as Callback Arguments 

Before getting into the details of delegates and lambdas, a quick overview.

You can think of a delegate as an object that represents a method. You can use the delegate object to call the method that it represents instead of calling the method directly but there's little benefit to doing this just because you can. Delegates become useful when you pass them to other methods as arguments, so the called methods can call the method that the delegate references. When you pass the delegate around like this it's a callback argument and it's commonly done in all software, not just .Net. I don't talk alot about callbacks here but I do include an example of one that I made up as well as one used in .Net. When you're done learning about delegates and lambdas here, check out a related article, callbacks with delegates and interfaces to learn more about how they're used.

Here's where anonymous methods and lambdas come in. A lambda is just a cleaner looking C# syntax for callback arguments. Instead of passing a delegate object as a callback argument, you could pass the whole method itself in the form of an anonymous method. But you'd only do this if the method is short, like one or two lines; coding a longer method as an argument in a method call wouldn't be pretty. But even if your method is just one line, you probably wouldn't do this because C# offers what is called a lambda, which is simply another syntax to write an anonymous method and makes for slick looking code. There are a lot of .Net API's that take a callback argument and often the code that runs as a callback is very simple and short so it's easily written in lambda syntax. (Later, I'll show how easy lambdas are to understand.) So, I think of delegate objects and anoymous methods and lambdas all as delegates, though technically, you could disagree. It is correct to say that you can pass either a delegate or an anoymous method or a lambda as an argument to a method that takes a delegate as a parameter; they can all be used as callback arguments.

One of the important things the C# compiler does to support delegates as callback arguments is called delegate inference. It's key to understanding how delegates are used in C# and I'll get to it in due time, so read on. First we need to go to square one and understand exactly what a delegate is. I didn't understand C# delegates until I understood what the compiler was doing behind the scenes. Without this understanding I was just memorizing syntax. After reading articles online as well as several C# books, I still didn't really get it. (There are so many BAD tech books out there.) That is, until I found Jon Skeet and Jeffrey Richter. (Thanks guys, for two excellent C# books.) I experimented with some code and finally wrote this article to make sure I understood the concepts and so others might benefit.

Delegates in C# 1.0 

A delegate is an object like any other, which, in C# 1.0, you had to declare and instantiate. But new .Net 3.5 delegate types and a smarter C# 2.0 compiler made the code around delegates different; cleaner and what is often described as more expressive. We'll avoid these newer developments for now because while they allow for more expressive source code, they hide what a delegate really is. Here's what you had to do in C# 1.0:

1. Define a delegate type - A delegate type will define the signature of the method that it will refer to and is type-safe as a result. So before you create your delegate type, you need to know what method it will refer to.
2. Create an instance of the delegate type and assign it a value.
3. Use the delegate object for some purpose: "Invoke the delegate".

Even this C# 1.0 code should confuse you because the compiler is doing work for you behind the scenes, hiding the true nature of a delegate.

What is the C# 1.0 Compiler Doing?

Let's see what's going on here. When I defined the IsEvenDelegate type,

Now that looks more like something I'm used to. Now I can see that a delegate is a class like any other class. The delegate class inherits from MulticastDelegate, which MSDN tells us has a couple of Properties, Method and Target, which expose the fields, _target and _methodPtr. The Method property gets the method that the delegate represents and the Target gets the class instance of the method. So these fields together are looking like they could comprise a pointer to a method. We don't need to understand the nitty gritty of how this pointer-thing works in C# to understand delegates but we can now see that a delegate isn't exactly a pointer, C# is too high-level for that but it sure contains something that looks a lot like one you'd see in a lower level language.

But this is confusing: The constructor generated by the compiler takes two arguments but our constructor call in the source code passes in only one, the name of the method, so something's going on behind the scenes to create the _target and _methodPtr fields.

And finally, we see the Invoke method that we used. The BeginInvoke and AsyncCallback support asyncronous tasks, which we can ignore for this discussion.

So, a delegate is a type that wraps or encapsulates a method. We still don't know all the details of how everything's working, like exactly how the constructor is working or how the pointer works but that detailed knowledge isn't necessary to understand our delegate code.

C# 2.0 

C# 2.0 and .Net Framework 2.0 do even more to allow for cleaner and more concise code. The new functionality mystifies delegates even more for people who've not been coding C# from the beginning, which is why delegate tutorials usually start with the old ways of C# 1.0.

What's new?:

1. We no longer need to define a delegate type because, the .Net Framework 2.0 included a bunch of delegate types that define just about any method signature you'd ever need. The Predicate<T> type is a generic delegate that you can use to wrap any method that returns a bool and takes a single argument, a type of your choice. In our example we use an int; Predicate<int>. Besides Predicate<T>, the .Net library also includes the following delegate types, each aptly named for the kind of work they do.
   • A series of generic Func<> types for methods that take up to 16 arguments and return a value.
   • A series of Action Types for methods that take up to 10 arguments and return void.
   And there's more in the System namespace.
2. The compiler now does something called delegate inference which means you can assign the name of a method directly to a delegate variable; and you don't need the new keyword anymore. Delegate inference allows for clean and expressive code when passing a lambda statement to a method that has a delegate parameter, which you'll see in the real world example at the end of this article.
3. A compiler shortcut allows you to leave off the .Invoke. Now isEven, the delegate, is called just like IsEven(), the method.

Anonymous Methods 

In many cases, when the code that a delegate refers to is short, named methods are overkill and can be replaced by an anoymous method. Let's see how to eliminate our IsEven named method and assign our isEvenDelegate to an anoymous method.

We assigned the delegate directly to the code from the method. We've replaced the method name, IsEven, with the delegate keyword. Otherwise, the method looks the same as the named version. The return type, bool in this case, is implied by the method itself and the compiler is smart enough to figure out that "return(number % 2 == 0)" means the return type is a bool.

This code is fairly ugly but Lambda syntax comes to the rescue.

Lambdas 

A lambda isn't that scary; it's just another syntax for coding an anonymous method; a more terse syntax that's expressive and easy to code in many situations when passing a callback argument into a class library. The Linq extension methods on IEnumerable<T> are a prime example. As with most new language features, you'll have trouble understanding them unless you know what the compiler is doing behind the scenes.

Here's the basic syntax:

=> is the lambda operator. To the right of the lambda is the method body; the statements. To the left of the operator are the input arguments.

• The delegate keyword is gone.
• The paramter type is gone. The compiler figured out that the number param is an int.
• The return is gone.
• The parentheses and curly braces are gone.

We've eliminated all the noise. Anonymous methods are going the way of the dinosaurs, replaced by lambdas. They take a little getting used to but some practice will have you fluent in no time. You have to admit, they make for good looking code. However, when your lambdas start getting bigger, some punctuation is required. Once your lambda exceeds a few statements or a few input params, you might use a named method instead. It turns out that in the real world, in the .Net class library, there are many methods, (API's), that take a delegate that can usually be written with one statement. We'll see examples in a bit.

I mentioned earlier that .Net comes with lots of delegate types built in; Funcs and Actions and Predicates. Here are a few examples of statements that instantiate objects of a few of those built-in delegates using lambdas:

Note that there's another whole world of lambda expressions that has nothing to do with expressing a method or delegates. In another context, a lambda expression may be translated into a data structure called an expression tree and then processed by some other code that translates the tree into something completely different, like SQL statements to hit a backend relational databse. That's called LINQ to SQL. LINQ to XML translates the lamda expression into XML queries. You can even do Amazon.com searches with LINQ to Amazon, (yes it really exists). So don't get confused by apples when they're really oranges.

MulticastDelegate 

We saw earlier that Delegate inherits from System.MulticastDelegate, which has the fields that serve as the actual pointer to a method. It has another field, _invocationList, that supports chaining of delegate instances. You can chain delegate instances, sort of like a list of pointers to methods, so when you invoke the head delegate, the whole chain runs. The Delegate class has Combine() and Remove() methods to add or remove delegates from the list. I won't get into it here but mention it to be thorough. Events often use this feature to open itself to multiple subscribers. Jeffrey Richter's excellent book, CLR via C# has good information on the topic. You've got to read his book; he's got a 3rd edition out in 2010.

Play Time 

Here's a console app for experimenting. It includes :

• Examples of anonymous methods passed as arguments
• Lambdas
• Two different named methods to show a delegate argument as a callback

Real World .Net Example : List<T>.FindIndex(Predicate<T> match) 

The FindIndex method on List<T> receives a Predicate as an argument. The Predicate is a callback that the FindIndex method calls to determine what it's looking for. (I wrote an article on callbacks. that you might read if you're interested.) Here's the definition from MSDN along with the definition of Predicate :

The compiler is helping make this code expressive, (less clutter in the form of curlies, parens, no new keyword required for delegate instantiation, etc.).

Delegate inference is letting us assign an anonymous method, (which we wrote using lambda syntax), directly to a delegate, in this case a Predicate. The compiler, using delegate inference, is making sure that cars => car.Constains("Subaru") has the right signature for a Predicate, and then it creates code to instantiate a delegate type and assign our method to it.

For me, understanding delegate inference eliminated my lambda fears. Before, I'd look at a signature of a method that took some kind of delegate, like the Predicate in this example and I just didn't GET how an anoymous method argument passed muster. That stuff makes me crazy unless I know what's going on.

So because the compiler is doing this stuff for you, delegates, anonymous methods and lambdas start to look like the same thing; at least on the surface. I'm starting to use the words lambda and delegate interchangeably. Anonymous methods get left out in the cold because they're rarely used now that lambda syntax is available. So, there's lots going on behind the scenes but now that we know how it all works, we can can enjoy the expressivness and readability our code can have.

Linq 

The mother lode of methods that take delegate parameters are the Linq extension methods on IEnumerable<T>. I'd have used one for an example here but there's more to explain that is off topic. Now that you know delegates through and through, you're ready to tackle linq to objects. Check out my article on Linq to objects.

Variable Scope 

One last thing I'll throw in briefly about anonymous methods because it's interesting. A lambda or anonymous method has access to any variable in the method where the lambda is defined; it's called a captured variable once it has been referenced in the lambda. A captured variable will be immune from garbage collection once it has been captured by a delegate for possible use later. For more information on captured variables and closures in C# you've got to go to Jon Skeets blog on closures.

Add your comment: