我同意，对于POD类型的类，编译器可以为你做。然而，你可能认为简单的编译器可能会出错。所以最好还是让程序员来做。

我曾经有一个POD案例，其中两个字段是唯一的-所以比较永远不会被认为是正确的。然而，我所需要的比较只是在有效负载上进行比较——这是编译器永远无法理解或自己无法解决的问题。

此外，他们不需要花很长时间来写，不是吗?!

编译器不会知道你想要的是指针比较还是深层(内部)比较。

更安全的做法是不实现它，让程序员自己来做。然后他们可以做出所有他们喜欢的假设。

c++ 0x有一个默认函数的提议，所以你可以说default operator==; 我们已经了解到，把这些事情弄清楚是有帮助的。

从概念上讲，定义平等并不容易。即使对于POD数据，有人可能会说，即使字段是相同的，但它是不同的对象(在不同的地址)，它也不一定相等。这实际上取决于操作符的用法。不幸的是，你的编译器不是通灵的，不能推断。

除此之外，默认函数是搬起石头砸自己的脚的好方法。你描述的默认值基本上是为了保持与POD结构体的兼容性。然而，它们确实会造成足够多的破坏，让开发人员忘记它们或默认实现的语义。

定义default ==是不可能的，但是你可以定义default != via ==，你通常应该定义自己。 为此，你应该做以下事情:

#include <utility>
using namespace std::rel_ops;
...

class FooClass
{
public:
  bool operator== (const FooClass& other) const {
  // ...
  }
};

详情请访问http://www.cplusplus.com/reference/std/utility/rel_ops/。

此外，如果您定义操作符<，则在使用std::rel_ops时，可以从它推导出<=、>、>=的操作符。

但是在使用std::rel_ops时应该小心，因为可以为您不期望的类型推导出比较运算符。

从基本操作符推断相关操作符的更可取的方法是使用boost::操作符。

boost中使用的方法更好，因为它为您只需要的类定义了operator的用法，而不是为作用域内的所有类定义了operator的用法。

您还可以从“+=”生成“+”，从“-=”生成“-”，等等…(见完整列表)

如果编译器可以提供默认的复制构造函数，它就应该能够提供类似的默认操作符==()，这在一定程度上是有意义的。我认为决定不为该操作符提供编译器生成的默认构造函数的原因可以从Stroustrup在“c++的设计和发展”(第11.4.1节-复制的控制)中关于默认复制构造函数的描述中猜到:

我个人认为这很不幸 定义的复制操作 默认和我禁止复制 我的许多类的对象。 然而，c++继承了它的默认值 赋值和复制构造函数 C，它们经常被使用。

因此，问题不应该是“为什么c++没有默认的操作符==()?”，而应该是“为什么c++有默认的赋值和复制构造函数?”，答案是Stroustrup为了向后兼容C而不情愿地包含了这些项(可能是c++的大部分缺点的原因，但也可能是c++流行的主要原因)。

出于我自己的目的，在我的IDE中，我用于新类的代码片段包含私有赋值操作符和复制构造函数的声明，因此当我生成一个新类时，我没有得到默认的赋值和复制操作——如果我想让编译器能够为我生成这些操作，我必须显式地从private:节中删除这些操作的声明。

恕我直言，没有什么“好的”理由。有这么多人同意这个设计决策的原因是因为他们没有学会掌握基于值的语义的力量。人们需要编写大量的自定义复制构造函数、比较操作符和析构函数，因为它们在实现中使用原始指针。

在使用适当的智能指针(如std::shared_ptr)时，默认的复制构造函数通常是可以的，假设的默认比较运算符的明显实现也可以。

It's answered C++ didn't do == because C didn't, and here is why C provides only default = but no == at first place. C wanted to keep it simple: C implemented = by memcpy; however, == cannot be implemented by memcmp due to padding. Because padding is not initialized, memcmp says they are different even though they are the same. The same problem exists for empty class: memcmp says they are different because size of empty classes are not zero. It can be seen from above that implementing == is more complicated than implementing = in C. Some code example regarding this. Your correction is appreciated if I'm wrong.

在这个视频中，STL的创造者Alex Stepanov在13:00左右回答了这个问题。总结一下，在见证了c++的发展之后，他认为:

It's unfortunate that == and != are not implicitly declared (and Bjarne agrees with him). A correct language should have those things ready for you (he goes further on to suggest you should not be able to define a != that breaks the semantics of ==) The reason this is the case has its roots (as many of C++ problems) in C. There, the assignment operator is implicitly defined with bit by bit assignment but that wouldn't work for ==. A more detailed explanation can be found in this article from Bjarne Stroustrup. In the follow up question Why then wasn't a member by member comparison used he says an amazing thing : C was kind of a homegrown language and the guy implementing these stuff for Ritchie told him he found this to be hard to implement!

然后他说，在(遥远的)未来，==和!=将隐式生成。

即使在c++ 20中，编译器仍然不会隐式地为你生成operator==

struct foo
{
    std::string str;
    int n;
};

assert(foo{"Anton", 1} == foo{"Anton", 1}); // ill-formed

但是自c++ 20以来，你将获得显式默认==的能力:

struct foo
{
    std::string str;
    int n;

    // either member form
    bool operator==(foo const&) const = default;
    // ... or friend form
    friend bool operator==(foo const&, foo const&) = default;
};

默认==执行成员式==(与默认复制构造函数执行成员式复制构造相同)。新规则还提供了==和!=之间的预期关系。例如，通过上面的声明，我可以写:

assert(foo{"Anton", 1} == foo{"Anton", 1}); // ok!
assert(foo{"Anton", 1} != foo{"Anton", 2}); // ok!

这个特定的特性(默认操作符==以及==和!=之间的对称)来自一个提议，该提议是更广泛的语言特性操作符<=>的一部分。

这有什么好的理由吗?为什么执行逐个成员的比较是一个问题?

这在功能上可能不是问题，但就性能而言，默认的逐个成员的比较可能比默认的逐个成员的赋值/复制更不理想。与赋值顺序不同，比较顺序会影响性能，因为第一个不相等的成员意味着可以跳过其余的成员。如果有一些成员通常是相等的，你想在最后比较它们，而编译器不知道哪些成员更可能是相等的。

考虑这个例子，其中verboseDescription是从一个相对较小的可能的天气描述集中选择的长字符串。

class LocalWeatherRecord {
    std::string verboseDescription;
    std::tm date;
    bool operator==(const LocalWeatherRecord& other){
        return date==other.date
            && verboseDescription==other.verboseDescription;
    // The above makes a lot more sense than
     // return verboseDescription==other.verboseDescription
     //     && date==other.date;
    // because some verboseDescriptions are liable to be same/similar
    }
}

(当然，如果编译器意识到比较没有副作用，它就有权忽略比较的顺序，但如果它自己没有更好的信息，它可能仍然会从源代码中获取查询。)

c++ 20提供了一种轻松实现默认比较运算符的方法。

例子来自cppreference.com:

class Point {
    int x;
    int y;
public:
    auto operator<=>(const Point&) const = default;
    // ... non-comparison functions ...
};

// compiler implicitly declares operator== and all four relational operators work
Point pt1, pt2;
if (pt1 == pt2) { /*...*/ } // ok, calls implicit Point::operator==
std::set<Point> s; // ok
s.insert(pt1); // ok
if (pt1 <= pt2) { /*...*/ } // ok, makes only a single call to Point::operator<=>

这样，随着时间的推移，这个问题的答案仍然是完整的:从c++ 20开始，它可以通过命令auto操作符自动生成<=>(const foo&) const = default;

它将生成所有的运算符:==，!=，<，<=，>和>=，详细信息请参见https://en.cppreference.com/w/cpp/language/default_comparisons。

由于操作员的外观<=>，它被称为宇宙飞船操作员。另见为什么在c++中我们需要太空船<=>操作符?

EDIT:同样在c++ 11中，std::tie也提供了一个相当简洁的替代品，有关bool操作符<(…)的完整代码示例，请参阅https://en.cppreference.com/w/cpp/utility/tuple/tie。有趣的部分，改变为使用==是:

#include <tuple>

struct S {
………
bool operator==(const S& rhs) const
    {
        // compares n to rhs.n,
        // then s to rhs.s,
        // then d to rhs.d
        return std::tie(n, s, d) == std::tie(rhs.n, rhs.s, rhs.d);
    }
};

tie适用于所有比较操作符，并被编译器完全优化。