运算符重载——禁止真的合理吗？

Question

Java 禁止运算符重载，但来自 C++，我看不出有任何理由这样做。在运算符符号与其他符号一样的语言中，相同的规则适用于“+”和“加号”，并且没有问题。那么有什么意义呢？

编辑：更具体地说，请告诉我重载“+”的缺点可能会过度重载“等于”。

Answer 1

要点是，例如，每当您看到代码中使用加号时，只要您知道其操作数的类型（您在 Java 中总是这样做，因为它是强类型的），您就可以准确地知道它的作用。

Answer 2

就像 Java 中的许多其他东西一样，这是一个限制，因为如果使用不当可能会造成混乱。 （类似于指针算术被禁止，因为它容易出错。）我是 Java 的忠实粉丝，但我通常认为不应该仅仅因为它可能就禁止它滥用。

例如，BigInteger 将从重载 + 运算符中受益匪浅。

Answer 3

好吧，我会尝试一下，假设 Gabriel Ščerbák 这样做的原因比反对一种语言更好。

对我来说，问题之一是可管理的复杂性：我面前的代码有多少是我必须解码的，而不是简单阅读的？

在大多数传统语言中，当看到表达式a + b时，我就知道会发生什么。变量a 和b 将被添加到一起。我非常有信心，在幕后，代码将是非常简洁、非常快速的本机机器代码，它将两个数字相加，无论数字是短整数、双精度还是两者的某种混合。 我可能还必须假设这些可能是连接的字符串，但这是对一个完全不同的问题的咆哮 - 但如果你从正确的角度观察它，就会对这个咆哮进行调味。）

（在某些语言中， 自己的用户定义类型——比如无所不在的 Complex 类型（以及为什么 Complex 不是现代语言中的标准数据类型，这是我无法理解的，但这又是对不同的问题）——如果我重载一个运算符（或者更确切地说，如果该运算符对我来说重载了——比如说，我正在使用一个库），如果没有仔细观察代码，我将不知道我在现在在对象上调用（可能是虚拟的）方法，而不是在幕后为我生成非常紧凑、简洁的代码。我不会知道隐藏的转换、隐藏的临时变量、……嗯，编写许多运算符所涉及的一切。为了找出代码中到底发生了什么，我必须非常密切地关注每一行，并跟踪可能距离代码中当前位置三个屏幕的声明。说这阻碍了我对眼前代码的理解是轻描淡写的。重要的细节正在丢失，因为语法糖让东西变得太美味了。

当我被迫在对象上使用显式方法（甚至是适用的静态方法或全局方法）时，这对我来说是一个信号，在我阅读时，它告诉我潜在的成本开销和瓶颈等。我知道，甚至不用想一瞬间，我正在处理一个方法，我有调度开销，我可能有临时对象创建和删除开销，等等。一切都是就在我眼前——或者至少有足够的指标在我面前，我知道要更加小心。

我本质上并不反对运算符重载。有时它会使代码更清晰，确实如此，尤其是当您对许多令人困惑的表达式进行复杂的计算时。然而，我可以理解为什么有人可能不想将其放入他们的语言中。

从语言设计者的角度来看，还有一个不喜欢运算符重载的进一步原因。运算符重载会导致语法非常非常困难。 C++ 已经因几乎不可解析而臭名昭著，它的一些构造（例如运算符重载）是造成这种情况的原因。同样，从编写该语言的人的角度来看，我完全可以理解为什么运算符重载被视为一个坏主意（或者是一个在实现中很糟糕的好主意）。

（当然，除了您已经拒绝的其他原因之外，这就是全部。我将在我过去的 C++ 岁月里提交我自己的 operator-,() 重载，只是为了真的很烦人。）

Answer 4

运算符重载本身没有问题，但它实际上是如何被使用的。只要你重载运算符使其有意义，语言仍然有意义，但如果你赋予运算符其他含义，就会使语言不一致。

（一个例子是左移 (<<) 和右移 (>>) 运算符如何在 C++ 中重载以表示“输入”和“输出”...）

因此，省略运算符时的推理超载可能是误用的风险大于操作员超载的好处。

Answer 5

我认为 Java 将通过扩展其运算符来覆盖内置的 Number 对象类型而受益匪浅。据说 Java 的早期（1.0 之前）版本就拥有它（因为没有原语 - 一切都是对象），但当时的 VM 技术使其从性能角度来看令人望而却步。

但就允许用户定义的运算符重载而言，它通常不符合 Java 语言的精神。主要问题很简单，很难实现一个与跨对象类型的数学期望一致的运算符，并且它将为许多糟糕的实现打开大门，从而导致很难找到（因此昂贵）错误。您只需查看一般 Java 代码中有多少错误的 equals 实现（如违反约定），问题只会变得更糟。

当然，有些语言优先考虑功能和语法美感，而不是这些问题，并且赋予它们更多的功能。它只是不是Java。

编辑：自定义 + 运算符与自定义 == 实现（在 Java 中的 equals(Object) 方法中捕获）有何不同？事实并非如此。只是由于允许操作符重载，对于六年级学生来说直观的事情变得不真实了。 equals(Object) 实现的现实经验表明，如此复杂的契约在现实世界中如何变得难以执行。

进一步编辑：让我澄清一下上面的内容，因为我在编辑时缩短了它并失去了重点。数学中的 + 运算符具有某些属性，其中之一是两边数字的出现顺序并不重要 - 它具有相同的结果。因此，考虑一下 + 向集合执行添加的最简单情况：

  Collection a = ...
  Collection b = ...
  a + b;
  System.out.println(a);
  System.out.println(b);

对 + 的直观理解会导致 a + b 的预期> 或 b + a 会给出相同的结果，但它们当然不会。开始混合两种对象类型，在其 plus 方法中将彼此作为参数（例如 Collection 和 String），事情会变得更难以理解。

现在当然可以在易于理解的对象上设计运算符，并产生比没有它们更好、更易读和更容易理解的代码。但关键是，在本土企业 API 中，您最终看到的往往是混淆的代码。

Answer 6

存在一些问题：

• 由于惰性求值，重载逻辑运算符会产生副作用。
• 即使在数学类型中也存在歧义，（3dpoint * 3dpoint）是交叉或缩放产品
• 您无法定义新的运算符，因此人们以新颖的方式重用现有运算符，例如。 “string1%string2”表示将 string1 拆分为 string2。

但即使完全禁止，你也不能总是保护白痴免受他们自己的侵害。