C# properties syntactic-sugar reference-parameters

C#属性和ref参数，为什么没有糖？

发布于 2024-07-13 13:43:49 字数 731 浏览 10 评论 0原文

我刚刚在 C# 中工作时遇到了此错误消息

属性或索引器不能作为 out 或 ref 参数传递

我知道导致此问题的原因，并快速解决了创建正确类型的局部变量、将其作为 out/ 调用函数的问题ref 参数，然后将其分配回属性：

RefFn(ref obj.prop);

变成

{
    var t = obj.prop;
    RefFn(ref t);
    obj.prop = t;
}

显然，如果属性不支持在当前上下文中获取和设置，则这将失败。

为什么 C# 不为我做到这一点？

我能想到这可能会导致问题的唯一情况是：

线程
异常

对于线程来说，转换会影响写入发生的时间（在函数调用之后与函数调用中），但我宁愿怀疑依赖于此的任何代码当它破裂时，很少有人同情。

对于例外情况，需要关注的是；如果函数分配给多个 ref 参数之一而不是抛出异常，会发生什么情况？任何简单的解决方案都会导致所有参数被分配或没有被分配，而有些参数应该分配，有些不应该分配。我再次认为这种语言的使用不会得到支持。

注意：我了解生成此错误消息的机制。我正在寻找的是 C# 不自动实现简单解决方法的基本原理。

原文

I just ran across this error message while working in C#

A property or indexer may not be passed as an out or ref parameter

I known what caused this and did the quick solution of creating a local variable of the correct type, calling the function with it as the out/ref parameter and then assigning it back to the property:

RefFn(ref obj.prop);

turns into

{
    var t = obj.prop;
    RefFn(ref t);
    obj.prop = t;
}

Clearly this would fail if the property doesn't support get and set in the current context.

Why doesn't C# just do that for me?

The only cases where I can think of where this might cause problems are:

threading
exceptions

For threading that transformation affects when the writes happen (after the function call vs. in the function call), but I rather suspect any code that counts on that would get little sympathy when it breaks.

For exceptions, the concern would be; what happens if the function assigns to one of several ref parameters than throws? Any trivial solution would result in all or none of the parameters being assigned to when some should be and some should not be. Again I don't think this would be supported use of the language.

Note: I understand the mechanics of why this error messages is generated. What I'm looking for is the rationale for why C# doesn't automatically implement the trivial workaround.

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

雨落星ぅ辰 2024-07-20 13:43:49

因为您正在传递索引器的结果，这实际上是方法调用的结果。无法保证索引器属性也有一个 setter，并且当开发人员认为他的属性将在没有调用 setter 的情况下被设置时，通过 ref 传递它会导致开发人员的错误安全。

在更技术的层面上， ref 和 out 传递传入它们的对象的内存地址，并且要设置属性，您必须调用 setter，因此不能保证该属性实际上会被更改，特别是当属性类型为不可变的。 ref 和 out 不仅仅设置方法返回时的值，它们还将实际的内存引用传递给对象本身。

回复收藏 0 原文

荒岛晴空 2024-07-20 13:43:49

属性只不过是 Java 风格的 getX/setX 方法的语法糖。对于方法上的“ref”来说没有多大意义。在您的实例中，这是有意义的，因为您的属性只是删除字段。属性不必只是存根，因此框架不能允许在属性上使用“ref”。

编辑：好吧，简单的答案是，属性 getter 或 setter 可能包含的不仅仅是字段读/写，这一事实使得允许排序是不受欢迎的，更不用说可能是意外的了你建议的糖。这并不是说我以前不需要这个功能，只是我理解为什么他们不想提供它。

回复收藏 0 原文

故事↓在人 2024-07-20 13:43:49

仅供参考，C# 4.0 将会有一些像这样的糖，但仅在调用互操作方法时 - 部分原因是 ref 的纯粹倾向这个场景。我还没有对其进行太多测试（在CTP中）；我们得看看结果如何……

回复收藏 0 原文

野味少女 2024-07-20 13:43:49

您可以将字段与 ref/out 一起使用，但不能与属性一起使用。原因是属性实际上只是特殊方法的语法快捷方式。编译器实际上将 get / set 属性转换为相应的 get_X 和 set_X 方法，因为 CLR 没有立即支持属性。

回复收藏 0 原文

是伱的 2024-07-20 13:43:49

它不是线程安全的；如果两个线程同时创建自己的属性值副本并将它们作为 ref 参数传递给函数，则只有其中一个线程最终回到属性中。

class Program
{
  static int PropertyX { get; set; }

  static void Main()
  {
    PropertyX = 0;

    // Sugared from: 
    // WaitCallback w = (o) => WaitAndIncrement(500, ref PropertyX);
    WaitCallback w = (o) => {
      int x1 = PropertyX;
      WaitAndIncrement(500, ref x1);
      PropertyX = x1;
    };
    // end sugar

    ThreadPool.QueueUserWorkItem(w);

    // Sugared from: 
    // WaitAndIncrement(1000, ref PropertyX);
    int x2 = PropertyX;      
    WaitAndIncrement(1000, ref x2);
    PropertyX = x2;
    // end sugar

    Console.WriteLine(PropertyX);
  }

  static void WaitAndIncrement(int wait, ref int i)
  {
    Thread.Sleep(wait);
    i++;
  }
}

PropertyX 最终为 1，而字段或局部变量则为 2。

该代码示例还强调了在要求编译器执行甜蜜操作时，匿名方法等内容带来的困难。

It wouldn't be thread-safe; if two threads simultaneously create their own copies of the property value and pass them to functions as ref parameters, only one of them ends up back in the property.

class Program
{
  static int PropertyX { get; set; }

  static void Main()
  {
    PropertyX = 0;

    // Sugared from: 
    // WaitCallback w = (o) => WaitAndIncrement(500, ref PropertyX);
    WaitCallback w = (o) => {
      int x1 = PropertyX;
      WaitAndIncrement(500, ref x1);
      PropertyX = x1;
    };
    // end sugar

    ThreadPool.QueueUserWorkItem(w);

    // Sugared from: 
    // WaitAndIncrement(1000, ref PropertyX);
    int x2 = PropertyX;      
    WaitAndIncrement(1000, ref x2);
    PropertyX = x2;
    // end sugar

    Console.WriteLine(PropertyX);
  }

  static void WaitAndIncrement(int wait, ref int i)
  {
    Thread.Sleep(wait);
    i++;
  }
}

PropertyX ends up as 1, whereas a field or local variable would be 2.

That code sample also highlights the difficulties introduced by things like anonymous methods when asking the compiler to do sugary stuff.

回复收藏 0 原文