C++common_comparison_category公共比较

2026-04-11 00:40:27 1074阅读 0评论

`common_comparison_category`：C++20里那个“不声不响却救了你三次”的比较工具

上周帮同事调一个模板匹配失败的问题，现象很诡异：两个明明逻辑等价的 std::strong_ordering 值，在 std::is_eq 判断下却返回 false。查了半小时才发现，他把 auto 推导出的 strong_ordering 和手动写的 weak_ordering 混着传进同一个函数模板——编译器没报错，但比较语义悄悄变了。

这事儿让我想起 common_comparison_category：它不像 std::ranges::sort 那样常被挂在嘴边，也不像 std::span 那样一用就感知明显。但它真正在后台默默协调着不同比较结果类型的“方言互通”，尤其在泛型代码里，一旦忽略它，你的比较逻辑可能在悄无声息中失效。

C++20 引入了三类比较类别（strong_ordering、weak_ordering、partial_ordering），每种承载不同语义强度：strong 要求完全可区分且可交换；weak 允许等价但不可区分（比如浮点 NaN）；partial 连等价性都不保证（比如涉及 NaN 的浮点比较）。当你写一个泛型函数，比如：

template<typename T, typename U>
auto compare(const T& a, const U& b) {
    return a <=> b; // 返回类型取决于 T 和 U 的 operator<=>
}

这个 auto 推导出的类型，可能是 strong_ordering，也可能是 partial_ordering——取决于具体类型。如果后续你想统一用 == 0 判断相等，就得确保所有分支返回的类型支持该操作。而不同类型之间不能直接比较：strong_ordering{0} == partial_ordering{0} 是非法的。

这时候，std::common_comparison_category 就是那个“翻译官”。它不是运行时转换，而是在编译期计算：给定若干比较类别，推导出它们能共同升格到的最弱但安全的类型。例如：

common_comparison_category_t<strong_ordering, weak_ordering> → weak_ordering
common_comparison_category_t<weak_ordering, partial_ordering> → partial_ordering
common_comparison_category_t<strong_ordering, strong_ordering> → strong_ordering

关键点在于：它遵循“向下兼容”原则——结果类型必须能无损表达所有输入类型的语义信息。strong 可以降级为 weak（丢弃部分区分能力），但 weak 无法升级为 strong（那会虚假承诺可区分性）。

实际怎么用？别把它当黑盒工具调用。它真正的价值场景，是你在设计接受多个可比较类型的接口时，主动约束返回类型。比如写一个通用的 minmax_by_key 函数：

template<typename R1, typename R2>
auto minmax_result(R1 r1, R2 r2) {
    using Cat = std::common_comparison_category_t<
        std::compare_three_way_result_t<R1>,
        std::compare_three_way_result_t<R2>
    >;
    return std::pair<Cat, Cat>{r1 <=> r2, r2 <=> r1};
}

这里 Cat 就是安全交集——哪怕 R1 是 int（返回 strong_ordering），R2 是 float（返回 partial_ordering），Cat 自动变成 partial_ordering，后续对 pair 中两个值的任何操作（比如取 == 0）都合法且语义一致。

有个容易踩的坑：别试图用 common_comparison_category “修复”设计缺陷。比如你明知某个类型只支持 partial_ordering，却硬要它参与 strong 语义的算法——这时 common_... 给出的 partial_ordering 不是妥协，而是提醒：你的算法前提本身就不成立。它不会掩盖问题，只会让错误更早暴露。

再举个贴近日常的例子：写一个配置项合并逻辑，需要比较两个 std::optional<std::string> 的优先级。optional<T> 的 <=> 返回 partial_ordering（因为 nullopt 与任何值比较都是 std::partial_ordering::unordered）。如果你同时还要支持 std::variant<int, std::string>（其 <=> 是 weak_ordering），那么 common_comparison_category_t<partial_ordering, weak_ordering> 就是 partial_ordering——这意味着你必须处理 unordered 状态，不能假设所有情况都能分出大小。