为什么在许多C ++标准库代码中将不等式测试为（！（a == b））？

这是C ++标准库remove代码中的代码。为什么用不平等if (!(*first == val))来代替if (*first != val)？

 template <class ForwardIterator, class T>
      ForwardIterator remove (ForwardIterator first, ForwardIterator last, const T& val)
 {
     ForwardIterator result = first;
     while (first!=last) {
         if (!(*first == val)) {
             *result = *first;
             ++result;
         }
         ++first;
     }
     return result;
 }

因为这意味着对T的唯一要求是实现一个operator==。您可能需要T具有一个，operator!=但是这里的总体思路是，您应该尽可能减少模板用户的负担，而其他模板确实需要operator==。

STL中的大多数功能只能与operator<或一起使用operator==。这就要求用户仅实现这两个运算符（或有时至少其中之一）。例如std::set使用operator<（更确切地说std::less，operator<默认情况下调用哪个）而不operator>管理订单。remove您的示例中的模板是类似的情况-它仅使用operator==而不使用，operator!=因此operator!=不需要定义。

这是来自C ++标准库的删除代码。

错误。这不是在 C ++标准库remove的代码。这是C ++标准库函数的一种可能的内部实现remove。C ++标准没有规定实际的代码。它规定了函数原型和必需的行为。

换句话说：从严格的语言角度来看，您所看到的代码不存在。它可能来自编译器的标准库实现随附的某些头文件。请注意，C ++标准甚至不需要这些头文件存在。文件只是编译器实现者满足类似代码行#include <algorithm>（即std::remove提供可用功能和其他功能）的一种便捷方式。

为什么用不平等if (!(*first == val))来代替if (*first != val)？

因为仅operator==此功能需要。

对于自定义类型的运算符重载，该语言允许您执行各种奇怪的事情。您可以很好地创建一个具有重载operator==但没有重载的类operator!=。甚至更糟糕的是：您可能会超载，operator!=但会做完全不相关的事情。

考虑以下示例：

#include <algorithm>
#include <vector>

struct Example
{
    int i;

    Example() : i(0) {}

    bool operator==(Example const& other) const
    {
        return i == other.i;
    }

    bool operator!=(Example const& other) const
    {
        return i == 5; // weird, but nothing stops you
                       // from doing so
    }

};

int main()
{
  std::vector<Example> v(10);
  // ...
  auto it = std::remove(v.begin(), v.end(), Example());
  // ...
}

如果std::remove使用operator!=，则结果将完全不同。

这里有一些好的答案。我只想添加一点笔记。

像所有好的库一样，标准库在设计时（至少）牢记​​两个非常重要的原则：

1. 对您可以逃脱的图书馆用户承担最少的责任。这部分与使用界面时给他们最少的工作量有关。（例如，定义尽可能少的运算符）。它的另一部分与使它们不感到惊讶或要求它们检查错误代码有关（因此，请保持接口一致，并<stdexcept>在出现问题时引发异常）。

2. 消除所有逻辑冗余。只能从推导出所有比较operator<，那么为什么要求用户定义其他人呢？例如：

   （a> b）等于（b <a）

   （a> = b）等于！（a <b）

   （a == b）等同于！（（a <b）||（b <a））

   等等。

   当然，在此说明中，您可能会问为什么unordered_map要求operator==（至少默认情况下）而不是operator<。答案是，在哈希表中，我们所需要的唯一比较是相等性比较。因此，要求他们定义相等运算符在逻辑上更加一致（即对库用户更有意义）。要求operator<会造成混淆，因为尚不清楚为什么您需要它。

该EqualityComparable概念仅需要operator==定义。

因此，任何自称可以使用满足类型要求的功能EqualityComparable 都不能依赖于该operator!=类型对象的存在。（除非存在暗示存在的其他要求operator!=）。

最有前途的方法是找到一种确定是否可以为特定类型调用operator ==的方法，然后仅在可用时才支持它。在其他情况下，将引发异常。但是，迄今为止，尚无已知方法来检测是否适当定义了任意运算符表达式f == g。已知的最佳解决方案具有以下不良质量：

• 对于无法访问operator ==的对象（例如，因为它是私有的），在编译时失败。
• 如果调用operator ==不明确，则在编译时失败。
• 即使operator ==可能未编译，但如果operator ==声明正确，则似乎是正确的。

来自Boost FAQ：来源

知道要求==实施是一个负担，因此您永远不想通过要求!=实施。

对我个人而言，这是关于SOLID（面向对象设计）的L部分-Liskov替换原则：“程序中的对象应该可以用其子类型的实例替换，而不会改变该程序的正确性。” 在这种情况下，运算符！=可以替换为==和布尔逻辑中的布尔逆。