问题的答案
C++20将浮点类型引入为非类型模板参数（NTTP），通过将它们分类为结构类型。根据标准（[temp.type]/4），只有当两个非类型模板参数是等效的，它们才匹配。对于浮点值，相等性是通过位级相等性而不是值相等性来确定的。这意味着只有当两个浮点常量具有相同的对象表示（每个位都匹配）时，它们才被视为相同的模板参数。
因此，+0.0和-0.0在IEEE 754表示中仅在符号位上有所不同，因此形成了不同的模板实例化。同样，不同的NaN有效载荷也会创建不同的类型。这与运行时行为形成鲜明对比，在运行时+0.0 == -0.0评估为true，因为相等运算符实现了数学等价性，而模板机制要求物理身份。
生活中的实例
在构建一个用于物理仿真引擎的编译时维度分析库时，我们遇到了这个问题。我们使用double NTTP来表示物理常数（例如引力常数），并希望为零质量的理论情况（表示为0.0）专门化求解器。然而，一些constexpr计算在评估质心时通过特定的算术运算（例如-1.0 * 0.0）产生了-0.0。
当用户将这些计算的结果作为模板参数传递时，编译器选择了通用实现，而不是我们的ZeroMass专门化，导致性能下降40%，因为通用版本执行完整矩阵求逆，而不是返回恒等矩阵。
我们考虑了三种解决方案。首先，我们可以显式地为+0.0和-0.0进行专门化。这种方法保证了正确的行为，但增加了我们的维护负担，并且仍未能处理各种NaN表示或有效为零但由于舍入误差而具有不同位模式的值。
第二，我们考虑使用constexpr辅助函数规范化所有输入，强制符号位为零（例如，value == 0.0 ? 0.0 : value）。这个解决方案对零是稳健的，但需要在每个模板实例化周围添加包装宏，污染API，并使期望直接参数传递的用户困惑。
第三，我们实现了一个类型规范化层，使用if constexpr和std::bit_cast在我们的元函数入口点处规范化值，有效地将所有零视为正值，并将安静的NaN折叠为规范有效载荷。我们选择这个解决方案，因为它为库用户提供了透明性，同时确保了内部一致性。
实施后，我们记录了库通过位表示处理所有浮点NTTP。这解决了性能问题，尽管这要求开发人员意识到-0.0和+0.0在类型系统中是不同的配置状态。
候选人经常忽视的内容
为什么std::is_same_v<decltype(func<+0.0>()), decltype(func<-0.0>())>尽管+0.0 == -0.0为真，仍然评估为false？
模板实例化依赖于“一一定义规则”和精确的模板参数匹配。当编译器遇到func<+0.0>()时，它会对浮点文字的位模式进行哈希或比较。由于IEEE 754规定-0.0有其符号位设置，而+0.0则没有，因此编译器看到两个不同的常量值并生成两个不同的函数实例化。运行时的相等运算符实现了IEEE 754规范，规定有符号零相等，但模板机制在运行时语义应用之前操作于对象表示的层面。候选人经常假设因为值在数学上是等价的，所以它们应该产生相同的类型，将运行时值语义与编译时类型身份混淆。
为什么template<float F> struct S{}; S<1.0>尽管1.0在正常表达式中隐式可转换为float，仍然无法编译？
对于浮点类型的非类型模板参数，C++20标准明确要求模板参数必须与参数具有完全相同的类型；不允许标准浮点提升和转换（[temp.arg.nontype]/5）。文字1.0的类型是double，而不是float，因此不能直接绑定到float F。您必须使用float后缀：S<1.0f>。该限制的存在是因为模板变换和类型身份需要在不损失转换精度的情况下进行明确表示。初学者通常会忽视这一点，因为函数调用允许转换，但模板在考虑转换规则之前会执行精确的类型匹配。
不同的安静NaN（qNaN）有效载荷如何影响模板实例化，尽管它们都表示“不是一个数字”？
IEEE 754允许NaN值携带有效载荷位（诊断信息）。由于C++20模板等价性使用位级比较，因此具有不同有效载荷的两个NaN（例如在不同硬件上std::numeric_limits<double>::quiet_NaN()与0.0/0.0的结果）是不同的模板参数。如果代码路径为多个NaN位模式实例化模板，则可能导致代码膨胀，或者如果不同的翻译单元观察到不同的NaN表示，可能导致微妙的ODR违规，而程序员假定这是单一的专门化。候选人经常假设NaN是类似nullptr的单一值，但它实际上代表一系列位模式，每种在模板系统中都是不同的。