equal_to 和 not_equal_to：C++里那对“较真”的函数对象

你有没有在写哈希表自定义键时，被编译器一句 no match for call to 'std::equal_to<...>' 抓住过？或者调试 unordered_map 查找失败，翻了半天代码才发现——原来 operator== 写对了，但 std::equal_to 没跟着同步更新？

这不是小题大做。std::equal_to 和 std::not_equal_to 是标准库中一对低调但关键的函数对象（function object），它们不是语法糖，也不是可有可无的包装；它们是哈希容器底层比较逻辑的实际执行者，也是算法泛型接口中“相等性语义”的显式契约。

很多人以为 equal_to<T>()(a, b) 就是 a == b 的马甲——没错，默认情况下它确实调用 operator==。但问题恰恰出在这个“默认”上：一旦你自定义类型、重载了 ==，甚至用了 constexpr 或 noexcept 修饰，equal_to 是否还能无缝承接？答案得看你怎么用它。

举个真实场景：你写了一个轻量坐标结构体：

struct Point {
    int x, y;
    constexpr bool operator==(const Point& other) const noexcept {
        return x == other.x && y == other.y;
    }
};

这时候 std::unordered_set<Point> 能正常工作吗？能，但前提是你的哈希函数和 equal_to 保持语义一致。unordered_set 内部查找时，先用哈希值快速分桶，再用 equal_to<Point>{} 逐个比对桶内元素——它不调用你手写的 ==，而是通过 equal_to 的 operator() 去触发。而 std::equal_to<Point> 的 operator() 正好会转发到 Point::operator==，所以一切顺利。

但注意这个细节：equal_to 的 operator() 是 const 成员函数，且默认 noexcept（如果 T 的 == 是 noexcept）。如果你的 operator== 没加 noexcept，而容器内部做了异常安全假设，就可能埋下隐患——这解释了为什么有些人在升级编译器后突然遇到未定义行为：新标准更严格地依赖 noexcept 合约。

再来看 not_equal_to。它常被误认为只是 !(a == b) 的封装。其实不然。not_equal_to<T> 的 operator() 显式调用 operator!=（如果存在），否则才退回到 !(a == b)。这意味着：如果你只重载了 ==，没写 !=，not_equal_to 仍能工作；但如果你同时提供了 !=，且它和 == 的逻辑不互为补集（比如浮点比较中用了容差），那 not_equal_to 就会按你写的 != 执行——它尊重你明确定义的不等语义，而不是强行取反。

这点在算法中很实在。比如你用 std::find_if_not(v.begin(), v.end(), std::equal_to<int>{5})，本意是找第一个不等于 5 的元素。这里 equal_to<int>{5} 是一个临时函数对象，find_if_not 会对每个元素调用 f(elem)。它实际执行的是 5 == elem，而非 elem == 5——参数顺序很重要。equal_to<T> 的调用签名是 bool operator()(const T& x, const T& y) const，等价于 x == y。所以 equal_to<int>{5}(x) 判断的是 5 == x。如果你习惯写 x == 5，这里逻辑不变；但若 T 的 == 是非对称的（比如某些代理类），顺序就真会影响结果。

还有一点容易被忽略：equal_to<void> 和 not_equal_to<void> 是 C++14 引入的“透明函数对象”。它们不绑定具体类型，支持异构比较。比如：

std::unordered_map<std::string, int> m;
m.find("hello"); // 这里传 const char*，但 map 的 key 是 string

能成功，正是因为 unordered_map 默认用 std::equal_to<void>（C++20 起是 std::equal_to<>），其 operator() 接收任意两个可比较类型，并在编译期推导 == 是否合法。它让“字符串字面量直接查 map”这种日常操作免去了隐式构造 std::string 的开销。这是性能上的实打实收益，不是纸面特性。

那么，什么时候该显式用 equal_to 或 not_equal_to？

• 写通用算法模板时：明确表达“此处需要相等性判断”，比裸写 == 更具语义清晰度；
• 定制哈希容器的比较策略时：比如 unordered_set<MyType, MyHash, std::not_equal_to<MyType>> ——虽然少见，但当你需要“不等即冲突”的特殊逻辑时，它就是唯一出口；
• 调试容器行为异常时：把 equal_to<T> 单独拎出来测试，能隔离出是哈希函数问题，还是相等判断逻辑出错。

最后提醒一句：别为了“用而用”。std::equal_to<int>{}(a, b) 和 a == b 在绝大多数场合效果一致，但前者多了层类型约束和语义提示。它的价值不在功能替代，而在意图显化与契约强化——就像你在函数参数里写 std::string_view 而不是 const std::string&，不是因为它更快，而是告诉所有读者：“我只读，不修改，也不需要所有权”。

C++ 的函数对象从来不是炫技道具。它们是一根根细线，把类型、语义、性能和标准库的底层机制悄悄缝在一起。摸清 equal_to 和 not_equal_to 的脾气，不是为了多记两个名字，而是当你下次面对哈希容器的静默失效、或算法结果不合预期时，能立刻想到：先看看那个被忽略的比较契约，是不是悄悄松动了。