我非常支持让编译器为你做尽可能多的工作。当编写一个简单的类时，编译器可以为你提供以下“免费”:
默认(空)构造函数 复制构造函数 一个析构函数 赋值运算符(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
{ }
这有什么好的理由吗?为什么执行逐个成员的比较是一个问题?显然，如果类分配内存，那么你要小心，但对于一个简单的类，编译器肯定可以为你做这个?
当前回答
这有什么好的理由吗?为什么执行逐个成员的比较是一个问题?
这在功能上可能不是问题，但就性能而言，默认的逐个成员的比较可能比默认的逐个成员的赋值/复制更不理想。与赋值顺序不同，比较顺序会影响性能，因为第一个不相等的成员意味着可以跳过其余的成员。如果有一些成员通常是相等的，你想在最后比较它们，而编译器不知道哪些成员更可能是相等的。
考虑这个例子，其中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
}
}
(当然，如果编译器意识到比较没有副作用，它就有权忽略比较的顺序，但如果它自己没有更好的信息，它可能仍然会从源代码中获取查询。)
其他回答
定义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:节中删除这些操作的声明。
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<=>
这有什么好的理由吗?为什么执行逐个成员的比较是一个问题?
这在功能上可能不是问题，但就性能而言，默认的逐个成员的比较可能比默认的逐个成员的赋值/复制更不理想。与赋值顺序不同，比较顺序会影响性能，因为第一个不相等的成员意味着可以跳过其余的成员。如果有一些成员通常是相等的，你想在最后比较它们，而编译器不知道哪些成员更可能是相等的。
考虑这个例子，其中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
}
}
(当然，如果编译器意识到比较没有副作用，它就有权忽略比较的顺序，但如果它自己没有更好的信息，它可能仍然会从源代码中获取查询。)
从概念上讲，定义平等并不容易。即使对于POD数据，有人可能会说，即使字段是相同的，但它是不同的对象(在不同的地址)，它也不一定相等。这实际上取决于操作符的用法。不幸的是，你的编译器不是通灵的，不能推断。
除此之外，默认函数是搬起石头砸自己的脚的好方法。你描述的默认值基本上是为了保持与POD结构体的兼容性。然而，它们确实会造成足够多的破坏，让开发人员忘记它们或默认实现的语义。
