[C#]6.0新特性浅谈

时间:2022-01-04 09:49:19

原文:[C#]6.0新特性浅谈

C#6.0出来也有很长一段时间了,虽然新的特性和语法趋于稳定,但是对于大多数程序猿来说,想在工作中用上C#6.0估计还得等上不短的一段时间。
所以现在再来聊一聊新版本带来的新特性可能也还不算晚吧?

一、nameof关键字

这绝对是整个新版本最让我期待的内容,它给代码重构带来了巨大的便利。
先来看一下它是怎么使用的吧:

string s;
Console.WriteLine(nameof(s));
s = nameof(s.Length);
Console.WriteLine(nameof(String));
Console.WriteLine(nameof(string.Length));
Console.WriteLine(nameof(string.Substring));

运行结果:

s
String
Length
SubString

通过上面的示例,可以看出来以下几点:

1.它不在乎变量是否已经初始化
2.它构成了一个运算结果为字符串的(编译时)表达式
3.它可以用于取得类型名,但是nameof(string)是不能通过编译的,小写的string是关键字而不是类型(这一点很值得吐槽。。。)
4.它的括号里面可以直接从类型取得实例属性
5.它可以取得方法名

然后看这段代码的IL:

IL_0000: ldstr "s"
IL_0005: call void [mscorlib]System.Console::WriteLine(string)
IL_000a: ldstr "String"
IL_000f: call void [mscorlib]System.Console::WriteLine(string)
IL_0014: ldstr "Length"
IL_0019: call void [mscorlib]System.Console::WriteLine(string)
IL_001e: ldstr "Substring"
IL_0023: call void [mscorlib]System.Console::WriteLine(string)
IL_0028: ret

编译后看不到nameof的痕迹,编译器把nameof的运算结果硬编码了,所以说它是一个"编译时运算符"。
适用场景:

1.空引用异常信息构成
2.ToString方法
3.IList数据绑定的列名

主要吐槽一下第三条吧,这是我最近工作里遇到的很闹心的一个事情,什么时候用上了6.0就能彻底解决这个麻烦了。。。
想象一下以前绑定一个自定义类型的List到ListBox吧,要设定DisplayMember和ValueMember的话就只能是硬编码,像是这样:

listBox1.DisplayMember = "ID";
listBox1.ValueMember = "Content";

一旦要对这个绑定类型的属性名称进行更改,工作量简直不敢想象。。。好一点的做法是用一套常量来代替硬编码,但是这样带来的麻烦是还得记着常量名。
不过以后用上了nameof就爽快了,一个Ctrl+R,R通通搞定~

二、[.?]空引用判断操作符

这算是一个用于简洁代码的语法糖吧,个人觉得实用价值一般般。
先看怎么用的吧:

string s = null;
s = s?.Substring();
// string expr_07 = this.s;
// this.s = ((expr_07 != null) ? expr_07.Substring(0) : null);
Console.WriteLine(s == null);

第二行代码与第三行被注释掉的部分,在编译过后是完全相等的。
同时也就是说一旦用了[.?],返回值就有可能是null,所以对于原本返回值类型的成员,只能赋值给Nullable<?>了,比如这样:

string s = null;
int? i = s?.IndexOf(".");
int j = s.IndexOf(".");

至于之后再要用到变量i,很多情况下仍然需要对是否空值进行判断。。。
同时这个语法糖也带来了歧义,比如这样:

object tag = form?.Tag;

由于Form和Tag都是引用类型,都可能为null,如果变量tag是null,这时候是没办法知道到底是form还是Tag返回了null(除非再判断一次。。。)。

三、字符串嵌入值

同样是一个用于简洁代码的语法糖,先看怎么用吧:

int i = ;
Console.WriteLine($"{nameof(i)} + 1 = {i + 1}");
Console.WriteLine($"{i + 1} * {i + 1} = 4");

运行结果:

i +  = 2
2 * 2 = 4

然后是IL:

IL_0000: ldc.i4.1
IL_0001: stloc.0
IL_0002: ldstr "{0} + 1 = {1}"
IL_0007: ldstr "i"
IL_000c: ldloc.0
IL_000d: ldc.i4.1
IL_000e: add
IL_000f: box [mscorlib]System.Int32
IL_0014: call string [mscorlib]System.String::Format(string, object, object)
IL_0019: call void [mscorlib]System.Console::WriteLine(string)
IL_001e: ldstr "{0} * {1} = 4"
IL_0023: ldloc.0
IL_0024: ldc.i4.1
IL_0025: add
IL_0026: box [mscorlib]System.Int32
IL_002b: ldloc.0
IL_002c: ldc.i4.1
IL_002d: add
IL_002e: box [mscorlib]System.Int32
IL_0033: call string [mscorlib]System.String::Format(string, object, object)
IL_0038: call void [mscorlib]System.Console::WriteLine(string)
IL_003d: ret

可以看出来以下几点:

1.大括号可以用于包裹表达式
2.相同的表达式需要计算两次

介于第二条,对于资源消耗较多的运算,还是用一个中间变量放到$字符串中更好,要么直接使用String.Format。
同时需要注意的是,$和@同时使用的时候必须把$写在@之前,而在正则表达式中的大括号中的内容会被优先当做C#表达式计算一遍,比如:

Regex.IsMatch("AAA", $@"A{3}");
Regex.IsMatch("AAA", String.Format("A{0}", ))

上下两行的编译结果是一样的,然而这样的编译结果显然不是我们想要的,所以我建议在正则表达式上不要使用字符串嵌入值。

四、lambda方法体

仍然是用于简洁代码的特性,如下:

private void LambdaMethod() => Console.WriteLine(nameof(LambdaMethod));
private string LambdaProperty => nameof(LambdaProperty);

任何用一句话就能搞定的方法从此都可以扔掉大括号和return关键字了。注意第二行的内容,能且仅能实现属性的get方法,所以这构成了一个只读属性。
上面这两行内容其实就是相当于这样的:

private void LambdaMethod()
{
Console.WriteLine("LambdaMethod");
} private string LambdaProperty
{
get
{
return "LambdaProperty";
}
}

在以前的版本我也可能这么写:

private Action LambdaMethod = () => Console.WriteLine(nameof(LambdaMethod));

这种写法对于方法还好说,属性想要这么写就不行了。。。当然,这种写法总的来说是不可取的。

五、属性初始化器

这个特性算是盼星星盼月亮终于盼来了,虽然说重要性可能不是那么大,但是以前版本的C#居然不这么设计着实让我有些难以理解。。。
用法就像是在字段前加get set器,在属性后加赋值:

private string InitedProperty { get; set; } = "InitedProperty";

和上一条特性中的lambda属性看起来有点像,但是其实是有很大不同的:

1.带属性初始化器的属性就和自动set get器属性一样,是有自动生成的字段的;而lambda属性是不会自动生成私有字段的
2.属性初始化器的等号后只能是静态成员;而实例lambda属性中可以是任何表达式
3.属性初始化器等号后的表达式只会在类型加载时运算一次;而lambda属性的表达式会在每一次调用属性时即时运算
4.属性初始化器不影响属性可写性;而lambda属性就只能读了

基于以上第三条,如果初始化表达式耗费资源较多,应该使用属性初始化器而不是lambda属性。

六、索引初始化器

可以说这个语法糖是集合初始化器的升级版,让基于索引的集合初始化更加合理了。

现在初始化一个Dictionary可以这么写:

new Dictionary<int, string>
{
[] = "a",
[] = "e"
};

键值关系一目了然,而原来要初始化一个Dictionary得这么写:

new Dictionary<int, string>
{
{, "a"},
{, "b"}
};

光是一堆大括号就实在惹人吐槽。。。需要注意,集合初始化器与索引初始化器不能混合使用,当然我相信也没人会这么去做。。。
另外,下面这段代码也能够通过编译,不过运行时会出错:

new List<string>
{
[] = "a"
};

因为对于Dictionary,编译器知道该调用Add方法,而对于List,编译器只知道蠢蠢地对索引器进行赋值。。。
当然,不支持List的索引初始化一方面是因为集合初始化器的语法可以应付这种情况,另一方面也是因为可能出现这样的情况:

new List<string>
{
[] = "a",
[] = "c"
};

很显然List的Add方法没办法完成这项工作。。。

七、异常过滤器

这个算是新特性中较为重要也是改动很大的一个部分,先来看看怎么用的:

try
{
throw new IOException("Not Throw");
}
catch (IOException ex) when (ex.Message != "Need Throw")
{
Console.WriteLine(ex.Message);
}
catch (NullReferenceException ex)
{
Console.WriteLine(ex.Message);
throw;
}

运行结果:

Not Throw

这种过滤如果放在以前就得写得非常难看了:

try
{
throw new IOException("Not Throw");
}
catch (IOException ex)
{
if (ex.Message != "Need Throw")
{
Console.WriteLine(ex.Message);
}
else if (ex is NullReferenceException)
{
Console.WriteLine(ex2.Message);
throw;
}
else
{
throw
}
}

关键在于以前在catch块中捕获的异常没法传给下一个catch块了。
看一下新版代码的IL吧:

.try
{
IL_0000: ldstr "Not Throw"
IL_0005: newobj instance void [mscorlib]System.IO.IOException::.ctor(string)
IL_000a: throw
} // end .try
filter
{
IL_000b: isinst [mscorlib]System.IO.IOException
IL_0010: dup
IL_0011: brtrue.s IL_0017 IL_0013: pop
IL_0014: ldc.i4.0
IL_0015: br.s IL_002b IL_0017: stloc.0
IL_0018: ldloc.0
IL_0019: callvirt instance string [mscorlib]System.Exception::get_Message()
IL_001e: ldstr "Need Throw"
IL_0023: call bool [mscorlib]System.String::op_Inequality(string, string)
IL_0028: ldc.i4.0
IL_0029: cgt.un IL_002b: endfilter
} // end filter
catch
{
IL_002d: pop
IL_002e: ldloc.0
IL_002f: callvirt instance string [mscorlib]System.Exception::get_Message()
IL_0034: call void [mscorlib]System.Console::WriteLine(string)
IL_0039: leave.s IL_0047
} // end handler
catch [mscorlib]System.NullReferenceException
{
IL_003b: callvirt instance string [mscorlib]System.Exception::get_Message()
IL_0040: call void [mscorlib]System.Console::WriteLine(string)
IL_0045: rethrow
} // end handler

好像看到了什么不得了的东西,居然出现了一个filter块。看来第一段代码try块构造的异常完全没有进catch块,这一点与以前的处理完全不一样了。
同时注意到在filter块下面还有一个未标明异常类型的catch块,从内容来看就是对应到C#代码的when后第一个大括号。
filter块中大概是这么个流程:

1.检验异常类型,true时走下一步,false时进入空引用异常的catch块
2.对when中表达式进行计算
3.endfilter判断上一步的结果,true时进入对应的catch块,false时进入空引用异常的catch块

可以看到,when的作用就是在catch块前插入一个filter块,而endfilter指令做的事情就是依据堆栈顶的值选择进入这个catch块还是将控制转移到异常处理程序。

八、静态成员引用

这个特性很久以前就在Java中出现了,而C#6.0也终于将其引入。
其实早在引入扩展方法的时候就已经破坏了定义类型可知性,然而扩展方法带来的好处实在太大了。
使用方法如下:

using static System.String;
...
Console.WriteLine(Concat("a", "b"));

注意到Concat方法是来自于String类型,也就是说静态引用针对的是成员而不是类型,using static后面不一定是静态类型。
这个特效带来的好处当然就是方便省事咯,坏处也很明显,就是比扩展方法有过之而无不及的对定义类型可知性的破坏,所以在使用这个特性的时候还是需要非常谨慎。
适用的成员必须是所有人都很清楚来由的,比如WriteLine、Format,一看就能知道方法是在Console和String类型中定义,而不是当前类型。

九、catch、finally中的await

终于可以在异常处理中愉快地使用异步编程语法糖了:

private async void Test()
{
try
{
await new Task<int>(() =>
{
return ;
});
}
catch
{
await new Task<int>(() =>
{
return ;
});
}
finally
{
await new Task<int>(() =>
{
return ;
});
}
}

最后祝愿Win10能赶紧普及起来,这样广大的.Net程序员才能真正用上这些神兵利器。