我只回答你问题的第二部分，即:

如果没有这种可能性，那么究竟为什么c++将这两个操作符定义为两个不同的函数呢?

允许开发人员重载两者是有意义的一个原因是性能。您可以通过同时实现==和!=来允许优化。那么x != y可能比!(x == y)便宜。一些编译器可能能够为您优化它，但也可能不能，特别是当您有涉及大量分支的复杂对象时。

即使在Haskell中，开发人员非常重视法律和数学概念，仍然允许重载==和/=，正如您可以在这里看到的(http://hackage.haskell.org/package/base-4.9.0.0/docs/Prelude.html#v:-61--61-):

$ ghci
GHCi, version 7.10.2: http://www.haskell.org/ghc/  :? for help
λ> :i Eq
class Eq a where
  (==) :: a -> a -> Bool
  (/=) :: a -> a -> Bool
        -- Defined in `GHC.Classes'

这可能被认为是微观优化，但在某些情况下可能是合理的。

作为对编辑的回应;

也就是说，如果某些类型可能具有操作符==而没有!=，或者反之亦然，以及在什么情况下这样做有意义。

一般来说，不，这说不通。相等运算符和关系运算符通常是集合。如果存在平等，那么也存在不平等;小于，然后大于，以此类推，使用<= etc。类似的方法也应用于算术运算符，它们通常也是自然逻辑集。

这在std::rel_ops命名空间中得到了证明。如果实现了相等操作符和小于操作符，则使用该名称空间将提供其他名称，这些名称空间是根据原始实现的操作符实现的。

话虽如此，在某些条件或情况下，其中一个并不立即意味着另一个，或者不能在其他方面得到实施?是的，有，可以说很少，但它们确实存在;同样，正如rel_ops是它自己的名称空间所证明的那样。出于这个原因，允许它们独立实现可以让您利用语言来获得所需的语义，或者以一种对代码的用户或客户端来说仍然自然和直观的方式获得所需的语义。

前面提到的惰性求值就是一个很好的例子。另一个很好的例子是，给他们不等于或不等于的语义。一个类似的例子是位移位操作符<<和>>用于流插入和提取。虽然在一般的圈子里它可能会引起不满，但在某些特定领域它可能是有意义的。

有一些非常完善的约定，其中(a == b)和(a != b)都是假的，不一定是相反的。特别地，在SQL中，任何与NULL的比较都会产生NULL，而不是true或false。

如果可能的话，创建这样的新示例可能不是一个好主意，因为这太不直观了，但是如果您试图对现有的约定建模，那么可以选择使您的操作符在该上下文中表现得“正确”。

我只回答你问题的第二部分，即:

如果没有这种可能性，那么究竟为什么c++将这两个操作符定义为两个不同的函数呢?

允许开发人员重载两者是有意义的一个原因是性能。您可以通过同时实现==和!=来允许优化。那么x != y可能比!(x == y)便宜。一些编译器可能能够为您优化它，但也可能不能，特别是当您有涉及大量分支的复杂对象时。

即使在Haskell中，开发人员非常重视法律和数学概念，仍然允许重载==和/=，正如您可以在这里看到的(http://hackage.haskell.org/package/base-4.9.0.0/docs/Prelude.html#v:-61--61-):

$ ghci
GHCi, version 7.10.2: http://www.haskell.org/ghc/  :? for help
λ> :i Eq
class Eq a where
  (==) :: a -> a -> Bool
  (/=) :: a -> a -> Bool
        -- Defined in `GHC.Classes'

这可能被认为是微观优化，但在某些情况下可能是合理的。

权力越大，责任越大，或者至少是非常好的风格指南。

==和!=可以重载来做任何你想做的事情。这是福也是祸。不能保证!=意味着!(a==b)。

如果没有这种可能性，那么究竟为什么c++将这两个操作符定义为两个不同的函数呢?

因为你可以让它们超载，通过超载，你可以赋予它们一个与原来完全不同的含义。

例如，操作符<<，最初是位左移操作符，现在通常重载为插入操作符，如std::cout << something;和原来的意思完全不同。

因此，如果您接受重载操作符时操作符的含义会发生变化，那么就没有理由阻止user给operator ==赋予一个与operator !=不完全相反的含义，尽管这可能会令人困惑。