网站安全管理机制建设,wordpress页面添加关键词,进入建设银行的网站就打不了字,营销型网站设计招聘C中提供了const特性#xff0c;使用该特性定义的参数#xff0c;其所引用的参数或对象将不会被调用函数修改#xff08;当然const还提供了更多的特性#xff0c;参见“Const正确性”#xff09;。在新的建议中#xff0c;C#也将提供类似的特性。
只读ref参数
在C#中中提供了const特性使用该特性定义的参数其所引用的参数或对象将不会被调用函数修改当然const还提供了更多的特性参见“Const正确性”。在新的建议中C#也将提供类似的特性。
只读ref参数
在C#中“只读引用”也可称为“in参数”两者提供了类似的限制。只读引用的基本思想是如果用“readonly ref”或仅是“in”标注一个参数那么编译器会解释为“将该参数按引用传递以改进性能但不允许实际更改该参数”。该特性对于在高性能场景下的大型结构体尤为有用。在建议中引用了如下的例子
我们知道在XNA等图形库中的向量/矩阵数学运算符是具有ref操作符的这纯粹是出于性能上的考虑。Roslyn编译器本身就有代码使用了结构体以避免内存分配并可通过引用的方式传递结构体免除复制的繁琐。
该语法还结合了C版本的const。即参数本身是不可更改的参数所引用的对象或结构体中的所有数据也是不可更改的。
当前在通过引用传递一个参数时必须使用“ref”或“out”关键字。在这个建议实现后使用“in”参数无需受此限制。进而表达式的结果也可以传递进来当前这在VB中是允许的但是在C#中尚不允许。
实现细节
对比“ref”和“out”参数它们的重载规则具有相同的工作机制。
这依然有待议定但是当前的计划是不允许“in”参数被匿名函数或async函数捕获即生成一个闭包对象。捕获“in”参数的问题在于会导致一次拷贝这破坏了使用“in”参数的初衷即避免拷贝所导致的性能损耗。
将参数标为“readonly ref”或“in”并不会令引用值成为不可变值。虽然参数值无法被声明函数更改但可以在其它地方修改。无需使用多线程只需能访问参数所引用原始变量的方法即可。
在结构体上调用方法可能会导致问题。在建议中是这样说的
结构体的所有常规实例方法可转变mutate实例或是对实例暴露引用ref-expose因此必须要创建一个临时拷贝正如当前对接收者是只读域时的做法。
但是由于没有考虑向后兼容也不存在变通方案所以编译器只是给出一个警告以确保用户留意到这一隐式拷贝。
使用“out”参数时一个特殊的参数标识了是否需要“in”参数。该参数将被旧的编译器忽略因此没有向后兼容的问题。
只读ref返回
与该特性密切相关的是将ref returns标为只读的功能。开发人员使用“in”参数主要因为它能提供良好的性能但是“in”参数不允许返回表达式的结果。返回值必须是正常ref返回的一个合法变量其中可以包含数组元素、ref参数和对象中的域。
ref/in的扩展方法
“ref”扩展方法将允许扩展方法修改传递进来的结构体。需要编译器能验证传递给ref扩展方法的参数是可变的。
虽然“in”扩展方法不允许修改参数但对于性能敏感的代码依然十分有用尤其是结构体非常大的时候。这时当然不需要一个可变参数。
在上面两种情况下该特性只能用于结构体。
编辑按假定广泛使用了PureAttribute编译器将不允许对“in”扩展方法调用非PureAttribute的方法。但由于对性能并无太大改善因此不大可能广泛应用。
只读结构体
将结构体变量标为readonly可能会对性能产生影响。编译器无法确定某个调用是否会对结构体产生改动因此会默认能够修改并始终复制只读结构体变量的副本。
使用该特性开发人员可以在类型层面上将整个结构体标为只读。这样一来编译器就知道在通过只读结构体的变量暴露该只读结构体时不需要进行拷贝。
在建议中指出
唯一一个显而易见的问题在于是否需要将其中一些方法改为赋值mutator方法。
目前对只读结构体进行逐个控制只会增加不必要的复杂性我们可以后期需要时再行添加。
当前我们假定可变和不可变成员“混合”的结构体并不常见。此外可变结构体的部分变量通常需要是LValues从而避免隐式拷贝的影响。
缺点
建议还指出这些功能对已有代码不大可能有帮助但在如下新场景中会很有用例如
在计算能力关乎费用响应能力关乎竞争优势的云场景或数据中心场景下。对延迟有软性实时需求的游戏/VR/AR场景。
在建议中也提出了警告在“in”参数上的限制可循环作用于被调用函数。但这一问题并不严重因为已经可以使用“out”参数执行同一操作了。
原文地址http://www.infoq.com/cn/news/2017/04/Readonly-References .NET社区新闻深度好文微信中搜索dotNET跨平台或扫描二维码关注
