gpt4 book ai didi

C# 7.2 对运算符使用 "in parameter"

转载 作者:行者123 更新时间:2023-11-30 18:13:21 26 4
gpt4 key购买 nike

在 C# 7.2 中,我们看到引入了用于方法参数的 in 修饰符以将只读引用传递给对象。我正在使用 7.2 开发一个新的 .NET Standard 项目,出于好奇,我尝试在结构的相等运算符的参数上使用 in 关键字进行编译。

即- public static bool operator ==(在点 l,在点 r)

不是 - public static bool operator == (Point l, Point r)

最初我对它的工作原理感到有点惊讶,但在稍微考虑之后我意识到这两个版本的运算符之间可能没有功能差异。我想证实这些怀疑,但经过全面搜索后,我找不到任何明确讨论在运算符重载中使用 in 关键字的内容。

所以我的问题是这是否真的有功能上的差异,如果有,是否有任何特别的理由鼓励或不鼓励将 in 与运算符参数一起使用。我最初的想法是没有区别,特别是如果操作符是内联的。然而,如果它确实有所作为,似乎应该在任何地方都使用 in 参数(任何只读引用有意义的地方,即),因为它们提供了速度奖励,而且与 不同refout,不需要用户在传递对象时在前面加上这些关键字。这将允许更高效的值类型对象传递,而无需对方法和运算符的用户进行任何更改。

总的来说,这可能超出了大多数 C# 开发人员担心的那种小规模优化,但我很好奇它是否有效果。

最佳答案

whether or not this actually has a functional difference... My initial thoughts are that there is no difference, particularly if the operator is inlined

由于运算符 == 重载在 MSIL 中像常规静态方法一样被调用,因此它具有功能差异。它可以帮助避免像常规方法那样进行不必要的复制。

is there any particular reason to encourage or discourage the use of in with operator arguments.

根据 this article当值类型大于 System.IntPtr.Size 时,建议应用 in 修饰符。但重要的是值类型应该是 readonly struct。否则 in 修饰符会损害性能,因为编译器会在调用结构的方法和属性时创建防御副本,因为它们可以更改参数的状态。

关于C# 7.2 对运算符使用 "in parameter",我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/52785937/

26 4 0