我不明白反对运算符重载的论点

我刚刚读过Joel的其中一篇文章，他说：

通常，我必须承认我有点害怕隐藏事物的语言功能。当您看到代码时

i = j * 5;

…至少在C中，您知道j被乘以5，结果存储在i中。

但是，如果您在C ++中看到相同的代码片段，则您一无所知。没有。知道C ++中真正发生的事情的唯一方法是找出i和j是什么类型，这些类型可能在其他地方完全声明。这是因为j可能属于operator*重载类型，并且在您尝试将其乘以乘法时会表现出极大的机智。

（强调我。）害怕隐藏事物的语言功能吗？你怎么会害怕呢？隐藏事物（也称为抽象）不是面向对象编程的关键思想之一吗？每次调用方法时a.foo(b)，您都不知道该怎么做。您必须找出什么类型a和b是什么，然后才可能在其他地方声明它们。那么我们应该放弃面向对象的编程，因为它对程序员隐藏了太多的东西吗？

与可能有j * 5什么不同j.multiply(5)，您可能必须使用不支持运算符重载的语言编写？再次，您将必须找出方法j内部的类型和peek multiply，因为lo和bekeeper j可能是具有某种multiply方法的类型，该方法执行某些非常机智的操作。

“ Muahaha，我是一个邪恶的程序员，只为一个方法命名multiply，但实际上它是完全晦涩且不直观的，并且与加乘运算绝对无关。” 设计编程语言时是否必须考虑这种情况？然后，我们不得不放弃编程语言中的标识符，理由是它们可能会误导人！

如果您想知道方法的作用，则可以浏览文档或浏览实现内部。运算符重载只是语法糖，我完全不知道它如何改变游戏。

请赐教。

抽象的“隐藏”代码使您不必担心内部工作，而且经常也不必更改它们，但其目的并不是要阻止您查看它。我们只是对运营商做出假设，就像乔尔所说的那样，它可能在任何地方。具有要求在特定位置建立所有重载运算符的编程功能可能会有助于找到它，但是我不确定它会使使用它变得更容易。

我看不出*做比删除函数更类似于乘法的事情，而不是叫Get_Some_Data的函数。

恕我直言，诸如运算符重载之类的语言功能赋予了程序员更大的权力。众所周知，强大的力量伴随着巨大的责任。具有更多功能的功能还为您提供了更多射击脚部的方法，显然，应谨慎使用。

例如，它可以完美的重载+或*运算符class Matrix或class Complex。每个人都会立即知道这意味着什么。另一方面，对我来说+，即使是Java将其作为语言的一部分，而STL也是std::string使用运算符重载的，但这实际上并不意味着要串联字符串。

运算符重载使代码更清晰的另一个好例子是C ++中的智能指针。您希望智能指针的行为尽可能像常规指针一样，因此重载一元*和->运算符是很有意义的。

本质上，运算符重载不过是命名函数的另一种方式。并且有一个函数命名规则：名称必须是描述性的，以使函数立即可见。相同的确切规则适用于运算符重载。

在Haskell中，“ +”，“-”，“ *”，“ /”等仅仅是（中缀）函数。

您是否应该像“ 4加2”中那样将中缀函数命名为“加”？如果您的功能要做加法，那为什么不呢。您应该将“加号”功能命名为“ +”吗？为什么不。

我认为所谓的“运算符”的问题在于，它们大多类似于数学运算，并且解释它们的方式并不多，因此人们对这种方法/功能/运算符的功能寄予很高的期望。

编辑：使我的观点更加清楚

根据我看到的其他答案，我只能得出结论，对运算符重载的真正反对是对立即显而易见的代码的渴望。

这很悲惨，原因有两个：

1. 得出其逻辑结论后，代码应该立即显而易见的原则将使我们所有人仍然使用COBOL进行编码。
2. 您不会从显而易见的代码中学习。您需要花一些时间来思考代码的工作原理，然后从有意义的代码中学习。

我有点同意。

如果编写multiply(j,5)，则j可以是标量或矩阵类型multiply()，根据情况不同，其复杂程度或多或少j。但是，如果您完全放弃了重载的想法，则必须对函数进行命名，multiply_scalar()否则multiply_matrix()将使其变得显而易见。

在代码中，我们中的许多人会以一种方式来选择它，而在代码中我们大多数人会以另一种方式来使用它。但是，大多数代码都处于这两个极端之间的中间位置。在这里您更喜欢什么取决于您的背景和个人喜好。

我看到了运算符重载的两个问题。

1. 重载会更改运算符的语义，即使程序员不打算这样做也是如此。例如，当你超载&&，||或者,，你失去由这些运营商的内置变种暗示序列点（以及逻辑运算符的短路行为）。因此，即使语言允许，也最好不要重载这些运算符。
2. 有些人认为操作员重载是一个很好的功能，即使不是合适的解决方案，他们也开始在各处使用它。这会导致其他人在另一个方向上反应过度，并警告不要使用操作员重载。我不同意这两个小组，但要采取中间立场：运算符重载应谨慎使用，并且仅当
   • 对于域专家和软件专家而言，重载的运算符具有自然的含义。如果这两个组对操作员的自然含义不一致，请不要重载。
   • 对于所涉及的类型，运算符没有自然的含义，并且直接上下文（最好是相同的表达式，但不超过几行）始终使运算符的含义清楚。此类别的一个示例是operator<<流。

根据我的个人经验，Java允许多种方法但不允许重载运算符的方式意味着您每次看到一个运算符时都会确切知道它的作用。

您不必查看是否*调用奇怪的代码，而是知道它是一个乘法，并且其行为与Java语言规范所定义的方式完全相同。这意味着您可以专注于实际行为，而不是找出程序员定义的所有检票口东西。

换句话说，禁止操作员重载对读者（而不是写作者）有益，因此使程序更易于维护！

重载a * b和调用之间的区别multiply(a,b)是后者很容易被抢占。如果该multiply函数未针对不同类型进行重载，则可以准确地找到该函数将要执行的操作，而不必跟踪a和的类型b。

Linus Torvalds 关于运算符重载有一个有趣的论点。在诸如Linux内核开发之类的系统中，大多数更改是通过电子邮件通过补丁发送的，维护人员必须了解补丁在每个更改周围只有几行上下文的作用，这一点很重要。如果没有重载函数和运算符，则可以更轻松地以上下文无关的方式读取补丁，因为您不必遍历更改的文件来找出所有类型是什么，并检查重载的运算符。

我怀疑这与超出预期有关。我已经习惯了C ++，并且习惯了操作员的行为并不完全受语言的支配，并且当操作员做一些奇怪的事情时，您不会感到惊讶。如果您习惯于不具备该功能的语言，然后再看C ++代码，那么您会带来其他语言的期望，当发现重载的运算符做一些时髦的事情时，可能会感到惊讶。

我个人认为有区别。当您可以更改语言的内置语法的行为时，它的推理就变得更加不透明。不允许元编程的语言在语法上不那么强大，但在概念上更易于理解。

我认为重载数学运算符并不是C ++中运算符重载的真正问题。我认为不应该依赖表达式（即类型）上下文的重载运算符是“邪恶的”。例如超载, [ ] ( ) -> ->* new delete，甚至一元*。这些运营商对您有一定的期望，这些期望永远都不会改变。

我完全理解您不喜欢乔尔关于藏身的说法。我也不。对于内置数字类型之类的东西或您自己的矩阵之类的东西，最好使用“ +”号。我承认，将两个矩阵与'*'而不是'.multiply（）'相乘是一种简洁而优雅的做法。毕竟，在两种情况下我们都具有相同的抽象。

这里的问题是代码的可读性。在现实生活中，不是在矩阵乘法的学术示例中。例如，尤其是如果您的语言允许定义语言核心中最初不存在的运算符=:=。此时，还会出现很多其他问题。那该死的操作员是做什么的？我的意思是那件事的优先顺序是什么？什么是关联性？a =:= b =:= c真正执行的顺序是？

这已经是反对运算符重载的论点。还是不服气？检查优先级规则只花了您10秒钟？好吧，让我们走的更远。

如果您开始使用允许运算符重载的语言，例如流行的名称以“ S”开头的语言，您将很快了解到库设计人员喜欢重写运算符。当然，他们受过良好的教育，他们遵循最佳实践（这里没有玩世不恭），当我们分别看待它们时，所有它们的API都很有意义。

现在想象一下，您必须使用一些API，这些API大量使用了在单个代码中一起重载运算符的方式。甚至更好-您必须阅读一些类似的旧代码。这是操作员超负荷确实很糟糕的时候。基本上，如果一个地方有很多重载运算符，它们很快就会开始与程序代码中的其他非字母数字字符混合。它们将与非字母数字字符混合在一起，这些字符不是真正的运算符，而是一些更基本的语言语法元素，这些元素定义了诸如块和作用域，形状流控制语句之类的东西或表示一些元事物。您需要戴上眼镜并将眼睛移近LCD显示屏10厘米，以了解视觉混乱。

通常，我避免以非直观的方式使用运算符重载。也就是说，如果我有一个数值类，重载*是可以接受的（并鼓励）。但是，如果我有一个Employee类，重载*会做什么？换句话说，以直观的方式重载运算符，使其易于阅读和理解。

可接受/鼓励：

class Complex
{
public:
    double r;
    double i;

    Complex operator*(const Compex& rhs)
    {
        Complex result;
        result.r = (r * rhs.r) - (i * rhs.i);
        result.i = (r * rhs.i) + (i * rhs.r);
        return result;
    }
};

不能接受的：

class Employee
{
public:
    std::string name;
    std::string address;
    std::string phone_number;

    Employee operator* (const Employee& e)
    {
        // what the hell do I do here??
    }
};

除了在这里已经说过的话，还有一个反对运算符重载的论点。确实，如果您编写+，这很明显意味着您要在某些内容上添加一些内容。但这并非总是如此。

C ++本身就是一个很好的例子。stream << 1应该如何阅读？流向左移1？除非您明确知道C ++中的<<也会写入流，否则这根本不是显而易见的。但是，如果将此操作实现为方法，那么任何明智的开发人员都不会编写o.leftShift(1)，就像o.write(1)。

最重要的是，通过使运算符重载不可用，该语言使程序员可以考虑操作的名称。即使选择的名称不是完美的名称，误解名称也仍然比符号更难。

与详细说明的方法相比，运算符要短一些，但也不需要括号。括号相对不方便键入。而且您必须平衡它们。总的来说，与操作员相比，任何方法调用都需要三个字符的普通噪声。这使得使用运算符非常诱人。
为什么还要有人这样做cout << "Hello world"呢？

重载的问题在于，大多数程序员都非常懒惰，而大多数程序员负担不起。

使C ++程序员滥用运算符重载的原因不是它的存在，而是缺少执行方法调用的更整洁的方法。人们不仅担心操作员超载是可能的，而且还因为这样做已经完成。
请注意，例如在Ruby和Scala中，没有人担心操作符重载。除了事实之外，运算符的使用并不比方法更短，另一个原因是，Ruby 将运算符的重载限制在一个合理的最小值，而Scala 允许您声明自己的运算符，从而避免了琐碎的冲突。

运算符重载之所以令人恐惧，是因为有许多程序员甚至从未想过这*并不意味着简单地“乘法”，而诸如此类的方法foo.multiply(bar)至少立即指出该程序员有人编写了自定义乘法方法。在这一点上，他们想知道为什么要去调查。

我曾与处于“高级”职位的“高级程序员”一起工作，他们将创建称为“ CompareValues”的方法，该方法将接受2个参数，并将值从一个应用于另一个，然后返回布尔值。或称为“ LoadTheValues”的方法将进入数据库以获取其他3个对象，获取值，进行计算，修改this并将其保存到数据库。

如果我正在与这些类​​型的程序员一起工作，则我立即知道要调查他们所从事的工作。如果他们让操作员超负荷工作，除了假定他们照做并继续寻找外，我根本不知道他们做了。

在一个完美的世界中，或者在一个拥有完美程序员的团队中，操作员重载可能是一个很棒的工具。不过，我还没有在一个由完美的程序员组成的团队中工作，所以这很令人恐惧。