如何解决浮点类型作为C ++ 20中的模板参数

根据cppreference，C ++ 20现在支持模板中的浮点参数。但是，我无法在该站点以及其他站点上找到任何编译器支持信息。当前的gcc干线就是这样做的，其他都是负面的。

我想知道这是否是一个低优先级的功能，和/或什么时候可以期望它得到普遍支持。

我能找到的唯一相关的东西是： P0732R2非类型模板参数中的类类型。如果有人能简要解释一下，那是很荣幸的。

解决方法

似乎可以在这里回答的真正问题是关于此功能的历史，以便可以在上下文中理解任何编译器支持。

非类型模板参数类型的限制

人们已经wanting class-type non-type template parameters很长时间了。那里的答案有些缺乏。真正使对此类模板参数（实际上是非平凡的用户定义类型）的支持复杂的是其未知的 identity （身份）概念：给定

struct A {/*...*/};
template<A> struct X {};
constexpr A f() {/*...*/}
constexpr A g() {/*...*/}
X<f()> xf;
X<g()> &xg=xf;  // OK?

我们如何确定X<f()>和X<g()>是否为同一类型？对于整数，答案似乎直观上很明显，但是类类型可能类似于std::vector<int>，在这种情况下，我们可能拥有

// C++23,if that
using A=std::vector<int>;
constexpr A f() {return {1,2,3};}
constexpr A g() {
  A ret={1,3};
  ret.reserve(1000);
  return ret;
}

尽管具有不同的行为，但尚不清楚该两个对象都包含相同的值（因此与==相等）的事实。 >（ eg ，用于迭代器无效）。

P0732非类型模板参数中的类类型

确实，本文使用新的<=>运算符添加了对类类型非类型模板参数的支持。逻辑是默认运算符的类是“透明的比较”（使用的术语是“强结构平等”），因此程序员和编译器可以就身份的定义达成共识。

P1185 `<=> != ==`

后来人们意识到，==出于性能原因应分别为默认值（例如，它允许较早退出以比较不同长度的字符串），并定义强结构相等性已根据该运算符进行了重写（该操作符随默认<=>一起免费提供）。这不会影响这个故事，但是如果没有它，这条线索是不完整的。

P1714 NTTP不完整，没有浮点，双精度和长双精度！

我们发现，类类型的NTTP和constexpr std::bit_cast的无关功能允许将浮点值走私到std::array<std::byte,sizeof(float)>这样的类型的模板参数中。尽管存在float和（给定{{1的事实），但这种技巧将产生的语义是-0.0==0.0的每个表示形式都是不同的模板参数。 }}）float nan=std::numeric_limits<float>::quiet_NaN();。因此，建议使用这些语义，直接使用这些语义将浮点值用作模板参数，以避免鼓励广泛采用这种骇人的解决方法。

当时，关于{给定nan!=nan和template<auto> int vt;可能与x==y不同的想法引起了很多困惑，并且该提案被拒绝了需要比C ++ 20所能提供的更多的分析。

P1907R0与非类型模板参数不一致

事实证明，&vt<x>==&vt<y>在这方面有很多问题。甚至枚举（一直被允许作为模板参数类型）也可以重载==，而将它们用作模板参数则完全忽略了该重载。（这或多或少是必要的：这样的运算符可能在某些翻译单元中定义，而不是在其他翻译单元中定义，或者可能以不同的方式定义，或者具有内部链接，例如 etc 。）此外，实现需要做什么对模板参数进行的操作 canonicalize ：将一个模板参数（例如，调用）与另一个（例如，显式专门化）进行比较后者就前者而言已经以某种方式被识别，同时又以某种方式允许它们可能有所不同。

对于其他类型，此身份概念也已经与==不同。甚至P0732都没有将引用（也可以是模板参数的类型）与==进行比较，因为当然==并不意味着{{1} }。未被广泛认可的是指向成员的指针也违反了这种对应关系：由于在持续评估中它们的行为不同，因此将指向工会不同成员的指针作为模板参数是不同的尽管比较了x==y，并且被强制指向基类的指向成员的指针具有相似的行为（尽管未指定其比较，因此不允许将其作为常量求值的直接组成部分。）

事实上，GCC已于2019年11月实现了对类类型NTTP 的基本支持，而无需任何比较运算符。

P1837从C ++ 20删除类类型的NTTP

这些不一致之处如此之多，以至于有人提议将整个功能推迟到C ++ 23。面对如此受欢迎的功能中的众多问题，委托一个小组来指定保存该功能所需的重大更改。

P1907R1（结构类型）

这些有关类类型和浮点类型的模板参数的故事在P1907R0的修订版中重新融合，该修订版保留了名称，但将其主体替换为解决方案，以取代具有也提交给同一主题。（新的）想法是要认识到，比较从来就不是真正的紧密联系，并且模板参数唯一性的唯一一致模型是，如果在持续评估期间有任何的区分方式，则两个参数是不同的（具有前述的区分成员指针等的功能）。毕竟，如果两个模板参数产生相同的专业化，则该专业化必须具有 one 行为，并且必须与直接使用任一自变量获得的专业化相同。

虽然希望支持各种各样的类类型，但是几乎可以在C ++ 20的最后一刻引入（或重写）新功能的唯一可靠支持的类就是那些在这里，实现可以区分的每个值都可以由其客户端来区分，因此，只有那些具有所有 public 成员（递归地具有此属性）的值。对这些结构类型的限制并不像对集合的限制那样严格，因为只要是constexpr，任何构造过程都是允许的。它还为将来的语言版本提供了合理的扩展，以支持更多的类类型，甚至可以通过规范化（或序列化）而不是通过比较（不支持此类扩展）甚至支持&x==&y。

一般解决方案

这种新发现的理解与C ++ 20中的任何其他事物都没有关系。使用此模型的类类型NTTP可能是 C ++ 11 的一部分（该类引入了类类型的常量表达式）。支持立即扩展到工会，但逻辑并不仅仅局限于阶级。它还确定，长期以来对模板参数（禁止指向子对象的指针或具有浮点类型的禁止）也是出于对==的困惑而引起的，因此没有必要。（虽然出于技术原因，这不允许字符串文字作为模板参数，但它允许允许std::vector<T>模板参数指向静态字符数组的第一个字符。）

换句话说，最终激发P1714的力量是模板基本行为的不可避免的数学后果，而浮点模板自变量毕竟成为C ++ 20的一部分。但是，C ++ 20的原始提议实际上并未为C ++ 20指定浮点和类类型的NTTP，这使“编译器支持”文档变得复杂。

浮点类型作为C ++ 20中的模板参数