如果==和!=操作符实际上并不意味着相等，就像<<和>>流操作符并不意味着位移位一样。如果你把这些符号当作其他概念来对待，它们就不必相互排斥。

就相等而言，如果您的用例保证将对象视为不可比较的，那么每次比较都应该返回false(或者如果操作符返回非bool类型，则返回不可比较的结果类型)，那么这样做是有意义的。我想不出一个具体的情况，这将是必要的，但我可以看到它是足够合理的。

当a == b返回bool类型以外的值时，您不会希望语言自动将a != b重写为!(a == b)。有几个原因可以让它这样做。

您可能有表达式构建器对象，其中a == b不会也不打算执行任何比较，而只是构建一些表示a == b的表达式节点。

你可能有惰性求值，其中a == b不会也不打算直接执行任何比较，而是返回某种惰性<bool>，可以在以后的某个时间隐式或显式地转换为bool来实际执行比较。可能与表达式构建器对象结合使用，以便在求值之前完成表达式优化。

你可能有一些自定义的可选<T>模板类，其中给定可选变量T和u，你想允许T == u，但让它返回可选<bool>。

可能还有我没想到的事。即使在这些例子中，操作a == b和a != b都是有意义的，但a != b与!(a == b)不是一回事，因此需要单独的定义。

如果==和!=操作符实际上并不意味着相等，就像<<和>>流操作符并不意味着位移位一样。如果你把这些符号当作其他概念来对待，它们就不必相互排斥。

就相等而言，如果您的用例保证将对象视为不可比较的，那么每次比较都应该返回false(或者如果操作符返回非bool类型，则返回不可比较的结果类型)，那么这样做是有意义的。我想不出一个具体的情况，这将是必要的，但我可以看到它是足够合理的。

也许是一个不可比较的规则，其中a != b为假，a == b为假，就像一个无状态位。

if( !(a == b || a != b) ){
    // Stateless
}

enum BoolPlus {
    kFalse = 0,
    kTrue = 1,
    kFileNotFound = -1
}

BoolPlus operator==(File& other);
BoolPlus operator!=(File& other);

我不能证明这个操作符重载是正确的，但在上面的例子中，不可能定义操作符!作为运算符==的“对立面”。

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

如果没有这种可能性，那么究竟为什么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'

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