为什么要静态解析重载运算符?这对我来说似乎是一种奇怪的选择——我能想到的唯一优点是获得一些小的性能提升(但JIT有时也可以避免这个问题),代价是产生一些相当不直观的行为,也就是说,基本上我必须将运算符转发到虚函数才能获得所需的行为。
这只是从C++中继承过来的吗?还是还有其他很好的理由?
为什么要静态解析重载运算符?这对我来说似乎是一种奇怪的选择——我能想到的唯一优点是获得一些小的性能提升(但JIT有时也可以避免这个问题),代价是产生一些相当不直观的行为,也就是说,基本上我必须将运算符转发到虚函数才能获得所需的行为。
这只是从C++中继承过来的吗?还是还有其他很好的理由?
请查看Eric Lippert的文章为什么C#中的重载运算符总是静态的?
相反,当面临潜在的语言特性时,我们应该问自己的问题是“这个功能的吸引人的好处是否值得所有成本?” 成本远不止设计、开发、测试、文档编写和维护一个功能的平凡货币成本。还有更微妙的成本,例如,这个功能会使将来更改类型推断算法更加困难吗?这是否会让我们进入一个无法在不引入向后兼容性破坏的情况下进行更改的世界?等等。
在这种特定情况下,吸引人的好处很小。如果您想在C#中拥有虚拟分派重载运算符,可以非常轻松地使用静态部件构建它。 [...]
支持基于实例的运算符是可能的,但C#语言设计者认为与使其正常工作所需的努力相比,收益不大。
x * y
与x.multiply(y)
没有任何区别。 - user166390(int)?10 > (int?)null
... 最终有意义,但仍然让我感到有些痛苦 :( - user166390x op y
被解释为x.op(y)
似乎是合乎逻辑的选择)。我可以理解那里的不对称之处的争论。 - Voo我脑海中浮现出两件事,其中任何一件都可以独立地打破交易:
virtual
方法仅基于this
的运行时类型进行分派。