views:

3872

answers:

5

Once it is compiled, is there a difference between:

delegate { x = 0; }

and

() => { x = 0 }

?

+20  A: 

Short answer : no.

Longer answer that may not be relevant:

  • If you assign the lambda to a delegate type (such as Func or Action) you'll get an anonymous delegate.
  • If you assign the lambda to an Expression type, you'll get an expression tree instead of a anonymous delegate. The expression tree can then be compiled to an anonymous delegate.

Edit: Here's some links for Expressions.

  • System.Linq.Expression.Expression(TDelegate) (start here).
  • Linq in-memory with delegates (such as System.Func) uses System.Linq.Enumerable. Linq to SQL (and anything else) with expressions uses System.Linq.Queryable. Check out the parameters on those methods.
  • An Explanation from ScottGu. In a nutshell, Linq in-memory will produce a some anonymous methods to resolve your query. Linq to SQL will produce an expression tree that represents the query and then translate that tree into executable T-SQL. Linq to Entities will produce an expression tree that represents the query and then translate that tree into platform appropriate SQL.
David B
An Expression type? This sounds like new territory to me. Where can I find out more about Expression types and using expression trees in C#?
MojoFilter
Updated answer to explain.
David B
Even longer answer - there are fiddly reasons why they're convertible to different delegate types, too :)
Jon Skeet
+3  A: 

In the two examples avobe there's no difference, zero.

The expression

() => { x = 0 }

is a Lambda expression with statement body, so it can't be compiled as an expression tree. In fact it doesn't even compile cos it needs a semicolon after 0:

() => { x = 0; } //Lambda statement body 
() => x = 0  // lambda expression body, could be an expression tree.
Olmo
Surely that means there's a difference of "one will compile, the other won't" ;)
Jon Skeet
+2  A: 

David B is correct. Note that there can be advantages to using expression trees. LINQ to SQL will examine the expression tree and convert it to SQL.

You can also play tricks with lamdas and expression trees to effectively pass the names of class members to a framework in a refactoring-safe way. Moq is an example of this.

Daniel Plaisted
+22  A: 

I like David's answer, but I thought I'd be pedantic. The question says, "Once it is compiled" - which suggests that both expressions have been compiled. How could they both compile, but with one being converted to a delegate and one to an expression tree? It's a tricky one - you have to use another feature of anonymous methods; the only one which isn't shared by lambda expressions. If you specify an anonymous method without specifying a parameter list at all it is compatible with any delegate type returning void and without any ref/out parameters. Armed with this knowledge, we should be able to construct two overloads to make the expressions completely unambiguous but very different.

But disaster strikes! At least with C# 3.0, you can't convert a lambda expression with a block body into an expression - nor can you convert a lambda expression with an assignment in the body (even if it is used as the return value). This may change with C# 4.0 and .NET 4.0, which allow more to be expressed in an expression tree. So in other words, with the examples MojoFilter happened to give, the two will almost always be converted to the same thing. (More details in a minute.)

We can use the delegate parameters trick if we change the bodies a little bit though:

using System;
using System.Linq.Expressions;

public class Test
{
    static void Main()
    {
        int x = 0;
        Foo( () => x );
        Foo( delegate { return x; } );
    }

    static void Foo(Func<int, int> action)
    {
        Console.WriteLine("I suspect the anonymous method...");
    }

    static void Foo(Expression<Func<int>> func)
    {
        Console.WriteLine("I suspect the lambda expression...");
    }
}

But wait! We can differentiate between the two even without using expression trees, if we're cunning enough. The example below uses the overload resolution rules (and the anonymous delegate matching trick)...

using System;
using System.Linq.Expressions;

public class Base
{
    public void Foo(Action action)
    {
        Console.WriteLine("I suspect the lambda expression...");
    }
}

public class Derived : Base
{
    public void Foo(Action<int> action)
    {
        Console.WriteLine("I suspect the anonymous method...");
    }
}

class Test
{
    static void Main()
    {
        Derived d = new Derived();
        int x = 0;
        d.Foo( () => { x = 0; } );
        d.Foo( delegate { x = 0; } );
    }
}

Ouch. Remember kids, every time you overload a methods from a base class, a little kitten starts crying.

Jon Skeet
I've read it, and thanks, explanation is good :)
Vin
I got out my popcorn and read the whole thing. That's some distinction that I would probably never think about even if I was staring it right in the face.
MojoFilter
Okay, removing the whiny bit at the end as clearly some people *have* read it :)
Jon Skeet
I'm a Jon Skeet fanboi, I read most of your answers when I come across them. =P
Erik Forbes
I knew some of this, but I must congratulate you on your ability to communicate it to humans.
David B
For anybody interested in the changes in .NET 4.0 (based on the CTP) - see http://marcgravell.blogspot.com/2008/11/future-expressions.html . Note that C# 4.0 doesn't do anything new yet as far as I can tell.
Marc Gravell
Jon, you rock.Erik, to be a true Skeet fanboi, you should be subscribed to his stack overflow rss like I am. Just stick http://stackoverflow.com/users/22656 into your feed reader.
Paul Batum
A: 

"Remember kids, every time you overload a methods from a base class, a little kitten starts crying."

haha. very nice!

dave
FYI, your response should be posted as a comment to the response that you are quoting. Responses should strictly be (attempted) answers to the posted question.
Canoehead