C++ 写运算符太累？rel_ops 帮你省下一半代码

每次新建一个结构体，是不是头疼要补全六个比较运算符？==, !=, <, >, <=, >=。手写不仅慢，还容易把符号搞反。这时候有个老伙计跳出来救场：std::rel_ops。

它藏在 <functional> 头文件里，专门负责帮你自动生成剩下的关系运算符。想象一下，你只需要像搭积木一样定义好基础的两块：operator== 和 operator<，剩下的四个就能自动补全。这种“以少打多”的思路，在早期 C++ 开发中可是极大的生产力工具。

#include <functional>

struct Point {
    int x, y;

    // 手动定义核心逻辑
    bool operator==(const Point& other) const { return x == other.x && y == other.y; }
    bool operator<(const Point& other) const { return x < other.x || (x == other.x && y < other.y); }
};

// 引入 rel_ops 命名空间
using namespace std::rel_ops; 

加上这两行后，Point 类型瞬间拥有了完整的比较能力。你在代码里直接用 p1 > p2 或者 p1 != p2，编译器会通过模板实例化找到对应的方法，无需再额外敲字。这是它的核心工作流。

但如果你现在的新项目还在用这个，可能就需要打个问号了。虽然 rel_ops 解决了输入量的问题，但它带来的隐患却不少。最典型的是命名冲突。一旦你的自定义类和某些标准库函数重名，或者引入了第三方库的命名空间，rel_ops 可能会引发二义性错误，导致编译失败。调试这种错误时，往往让人抓狂。

更重要的是技术演进。C++11 之后，= default 的出现让 operator== 的初始化变得极其简单，甚至很多场景下不需要手动写逻辑。到了 C++20，三向比较符 <=> 更是直接终结了手动编写比较函数的时代。一行 <=> 搞定所有运算，既安全又高效。

所以，面对 rel_ops，现在的态度应该是：知其然，亦知其所以然。

如果你的工作涉及维护十年前的旧代码，遇到这段写法别急着删，知道它是干嘛的就行。但在撰写新业务逻辑时，除非为了极致兼容旧接口，否则建议优先使用 C++20 的 spaceship operator 或者 显式的默认构造函数。

技术没有绝对的对错，只有适不适合的场景。理解 rel_ops 的存在价值，能让你在面对遗留系统时不再手足无措；而了解它的局限性，则能确保你在新的征程里不走弯路。毕竟，真正的效率提升，从来不是单纯减少几行代码，而是选择更稳健的工具。