c++ - 为什么我需要包含 头来让 <=> 编译？

Question

我知道技术答案是:因为标准是这样说的。

但我对动机感到困惑:

我在默认的 <=> 中看不到任何“库” :它可能会返回一些技术上定义在 std 中的类型但从某种意义上说，它是一种“假库”类型，编译器必须know关于它，因为它必须能够默认operator <=>与 auto返回类型(更不用说好的编译器中的错误消息指定 <compare> 所以很明显这里有一个语言<=>库链接)。

所以我知道有一些 library functionality这可能需要我包括 <compare>但我不明白为什么默认 <=>要求我包含该头文件，因为无论如何编译器都必须了解制作 <=> 所需的一切信息。 .

注意:我知道大多数时候其他一些标准头文件会包含 <compare> ，这是一个关于语言/库设计的问题，而不是 C++ 强制我在没有充分理由的情况下写的额外一行。

Answer 1

it may return some type that is technically defined in std but it is a "fake library" type in a sense

那么， <=>返回 very much real 的类型, 实际上是在 <compare> 中定义的并在那里实现。与使用初始化列表构建 std::initializer_list<T> 的方式相同，这是一个真正的类型，实际上在 <initializer_list> 中定义.和 typeinfo在 <typeinfo> .

还有那些比较类型 - std::strong_ordering , std::weak_ordering , 和 std::partial_ordering (最初也是 std::strong_equality 和 std::weak_equality )——它们本身具有重要的转换语义和其他定义在它们上面的操作，我们可能希望在 future 改变。它们确实是非常特殊的语言类型，其中可转换性只在一个方向上进行，但与继承非常不同(总排序类型只有三个值，但部分排序类型有四个......)。将这些定义为真正的库类型，然后将它们的交互指定为真正的库代码，真的要容易得多。

that compiler must know about it since it must be able to default operator<=> with auto return type

有点，但不是真的。编译器知道类型的名称是什么，以及如何为基本类型生成它们的值，但它实际上不需要知道更多。返回类型的规则基本上是基于底层成员 <=> 的类型硬编码的。 s return，不需要知道那些实际类型是什么样子来做到这一点。然后你只是调用了做......无论如何的函数。

必须包含标题的成本是输入 #include <compare>然后解析它。编译器必须综合这些类型的成本是必须为每个 TU 支付的成本，无论它是否进行任何三向比较。另外，如果/当我们想要更改这些类型时，无论如何更改库类型比更改语言类型更容易。