我非常支持让编译器为你做尽可能多的工作。当编写一个简单的类时，编译器可以为你提供以下“免费”:
默认(空)构造函数 复制构造函数 一个析构函数 赋值运算符(operator=)
但是它似乎不能给你任何比较操作符——比如operator==或operator!=。例如:
class foo
{
public:
std::string str_;
int n_;
};
foo f1; // Works
foo f2(f1); // Works
foo f3;
f3 = f2; // Works
if (f3 == f2) // Fails
{ }
if (f3 != f2) // Fails
{ }
这有什么好的理由吗?为什么执行逐个成员的比较是一个问题?显然，如果类分配内存，那么你要小心，但对于一个简单的类，编译器肯定可以为你做这个?
当前回答
恕我直言，没有什么“好的”理由。有这么多人同意这个设计决策的原因是因为他们没有学会掌握基于值的语义的力量。人们需要编写大量的自定义复制构造函数、比较操作符和析构函数，因为它们在实现中使用原始指针。
在使用适当的智能指针(如std::shared_ptr)时，默认的复制构造函数通常是可以的，假设的默认比较运算符的明显实现也可以。
其他回答
从概念上讲，定义平等并不容易。即使对于POD数据，有人可能会说，即使字段是相同的，但它是不同的对象(在不同的地址)，它也不一定相等。这实际上取决于操作符的用法。不幸的是，你的编译器不是通灵的，不能推断。
除此之外，默认函数是搬起石头砸自己的脚的好方法。你描述的默认值基本上是为了保持与POD结构体的兼容性。然而，它们确实会造成足够多的破坏，让开发人员忘记它们或默认实现的语义。
我同意，对于POD类型的类，编译器可以为你做。然而，你可能认为简单的编译器可能会出错。所以最好还是让程序员来做。
我曾经有一个POD案例，其中两个字段是唯一的-所以比较永远不会被认为是正确的。然而，我所需要的比较只是在有效负载上进行比较——这是编译器永远无法理解或自己无法解决的问题。
此外，他们不需要花很长时间来写，不是吗?!
即使在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!
这个特定的特性(默认操作符==以及==和!=之间的对称)来自一个提议，该提议是更广泛的语言特性操作符<=>的一部分。
编译器不会知道你想要的是指针比较还是深层(内部)比较。
更安全的做法是不实现它，让程序员自己来做。然后他们可以做出所有他们喜欢的假设。
定义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的用法。
您还可以从“+=”生成“+”，从“-=”生成“-”，等等…(见完整列表)
