Java设计人员认为操作符重载带来的麻烦大于它的价值。就这么简单。

在一种每个对象变量实际上都是引用的语言中，运算符重载具有相当不合逻辑的额外危险——至少对c++程序员是这样。比较c#的==操作符重载和Object的情况。等号和对象。ReferenceEquals(或其他名称)。

这不是一个很好的理由来禁止它，而是一个实际的理由:

人们并不总是负责任地使用它。请看下面这个来自Python库scapy的例子:

>>> IP()
<IP |>
>>> IP()/TCP()
<IP frag=0 proto=TCP |<TCP |>>
>>> Ether()/IP()/TCP()
<Ether type=0x800 |<IP frag=0 proto=TCP |<TCP |>>>
>>> IP()/TCP()/"GET / HTTP/1.0\r\n\r\n"
<IP frag=0 proto=TCP |<TCP |<Raw load='GET / HTTP/1.0\r\n\r\n' |>>>
>>> Ether()/IP()/IP()/UDP()
<Ether type=0x800 |<IP frag=0 proto=IP |<IP frag=0 proto=UDP |<UDP |>>>>
>>> IP(proto=55)/TCP()
<IP frag=0 proto=55 |<TCP |>>

下面是解释:

/操作符用作两个操作符之间的复合操作符 层。当这样做时，下层可以有一个或多个它的 默认字段根据上层重载。(你仍然 可以给出你想要的值)。字符串可以用作原始层。

Groovy具有操作符重载，并且运行在JVM中。如果您不介意性能损失(每天都在减小)。它是基于方法名自动生成的。例如，'+'调用'plus(参数)'方法。

假设Java是实现语言，那么a、b和c都是对初始值为null的Complex类型的引用。还假设Complex是不可变的，就像前面提到的BigInteger和类似的不可变BigDecimal一样，我想你是指下面的意思，因为你将引用赋值给从添加b和c返回的Complex，而不是将这个引用与a进行比较。

不是: 复合物a, b, c;A = b + c; 简单得多: 复合物a, b, c;A = b.add(c);

Java设计人员认为操作符重载带来的麻烦大于它的价值。就这么简单。

在一种每个对象变量实际上都是引用的语言中，运算符重载具有相当不合逻辑的额外危险——至少对c++程序员是这样。比较c#的==操作符重载和Object的情况。等号和对象。ReferenceEquals(或其他名称)。

看看Boost吧。单位:链接文字

它通过操作符重载提供零开销的维数分析。这一点还能清楚多少呢?

quantity<force>     F = 2.0*newton;
quantity<length>    dx = 2.0*meter;
quantity<energy>    E = F * dx;
std::cout << "Energy = " << E << endl;

实际上会输出“Energy = 4 J”，这是正确的。