我是代表们的新手,我想知道第一个代码和第二个代码之间的差异
我有一个班级
public class FindPerson
{
public int Age;
public string Name;
public string Surname;
public FindPerson(string name, string surname, int age)
{
this.Age = age;
this.Surname = surname;
this.Name = name;
}
public override string ToString()
{
return "Name=" + this.Name + " Surname=" + this.Surname + ", Age=" + this.Age.ToString();
}
}
第一个代码
public void Test2()
{
List<FindPerson> lst = new List<FindPerson>();
lst.Add(new FindPerson("Alex","Sweit",31));
lst.Add(new FindPerson("Alex2", "Sweit", 30));
lst.Add(new FindPerson("Alex3", "Sweit", 34));
FindPerson iam = lst.Find(a => a.Name.Equals("Alex"));
}
第二段代码:
public void Test2()
{
List<FindPerson> lst = new List<FindPerson>();
lst.Add(new FindPerson("Alex","Sweit",31));
lst.Add(new FindPerson("Alex2", "Sweit", 30));
lst.Add(new FindPerson("Alex3", "Sweit", 34));
FindPerson iam2 = lst.Find(new Predicate<FindPerson>(delegate(FindPerson find)
{
return find.Name.Equals("Alex");
}));
}
我正在学习使用代表,但目前尚不清楚。
答案 0 :(得分:8)
这基本上是一回事。
{1}}语法是在C#2.0中引入的,而lambda语法是在C#3.0中引入的。它们的设计考虑了不同的目标,但服务于同一目的。
让我引用Eric Lippert(这是他排名前十的最差C#功能的第7位):
我认为所有相关人员都会同意,对于基本相同的东西,有两个不一致的语法是不幸的。但是,C#坚持使用它,因为现有的C#2.0代码仍然使用旧的语法。
C#2.0语法的“沉重感”在当时被看作是一种好处。想法是用户可能会对嵌套方法的这一新功能感到困惑,并且设计团队希望在那里调用一个明确的关键字,并将嵌套方法转换为委托。没有人能够看到未来知道在几年内需要更轻量级的语法。
现在你不会在新代码中看到delegate() { }
语法使用得太多,因为几乎每个人都喜欢较轻的lambda delegate() { }
语法。
=>
只需明确键入委托,不再需要委托。它曾经是C#1 IIRC的强制性要求。在大多数情况下可以推断出它可以省略(如果需要,请参阅here示例)。
它的存在是由于lambda由引擎盖下的类实例表示,在这种特殊情况下new Predicate<FindPerson>
就是那个类。 “原始”lambda本身是无类型的,但它可以隐式转换为任何兼容的委托类型。
例如,Predicate<T>
在此示例中是兼容的委托类型,但Predicate<FindPerson>
也是如此。同样的lambda也可以转换为Func<FindPerson, bool>
,但这是完全不同的事情。这就是为什么你不能在C#中编写Expression<Func<FindPerson, bool>>
的原因
var fn = (int x) => x;
的类型无法仅从此表达式中推断出来。
作为回顾,这些都是等价物:
fn
答案 1 :(得分:0)
第一个例子使用所谓的“lambda”表达式(在.Net 3.5中引入),这是一种更简洁,更简洁(我认为)表达匿名委托的更优雅方式。第二个代码是做同样事情的更老,更冗长的方式。
答案 2 :(得分:0)
它们在生成的IL
代码方面完全相同。第一个是更好的读写,但通常更常见。代表们现在很少使用。
答案 3 :(得分:0)
除了语法之外没有区别。 Find
方法需要Predicate<T>
作为参数,并且您决定使用new
关键字自行创建天气,或传递lambda表达式并让它编译器会为你做这件事。