为何std::nextafter非常量表达式？a2可编译z1却失败？

问题描述 #

为何以下代码中a2可正常编译，z1却无法编译？同时想问：为何std::nextafter不是常量表达式？

测试代码 #

#include <cmath>    // std::nextafter
#include <limits>   // std::numeric_limits

int main ()
{
    constexpr float a1 {1.f};
    constexpr float a2 {std::nextafter(a1, std::numeric_limits<float>::max())};
    constexpr float z0 {0.f};
    constexpr float z1 {std::nextafter(z0, std::numeric_limits<float>::max())};
    
    return 0;
}

编译报错信息 #

使用GCC 13.2编译时，报错如下：

In file included from <source>:1:
/opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/cmath: In function 'int main()':
<source>:9:39:   in 'constexpr' expansion of 'std::nextafter(((float)z0), std::numeric_limits<float>::max())'
/opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/cmath:2417:32: error: '__builtin_nextafterf(0.0f, 3.40282347e+38f)' is not a constant expression
 2417 |   { return __builtin_nextafterf(__x, __y); }

可见GCC可正常编译a2，但z1编译失败。另外注意：Clang 14.0和MSVC 19.38甚至无法编译a2。

问题解答 #

1. GCC中a2能编译、z1失败的原因 #

GCC做了非标准扩展，允许部分内置浮点数函数在特定场景下作为常量表达式计算，但这种支持有局限性：

• 当输入是非零常规浮点数（比如a1=1.f）时，__builtin_nextafterf的计算逻辑简单直接，编译器能在编译期确定结果，因此a2可以通过constexpr校验。
• 当输入是0.0f时，nextafter需要返回浮点数的最小正非正规数，这个计算涉及浮点数格式的底层细节，GCC的内置函数在这个场景下无法被认定为常量表达式，导致z1编译报错。

这种行为是GCC独有的扩展，并非C++标准要求，所以Clang、MSVC等编译器没有实现该逻辑，自然连a2也无法编译。

2. 为什么std::nextafter不是常量表达式？ #

在C++26之前的标准中，std::nextafter并未被定义为常量表达式，原因主要有两点：

• 浮点数操作的复杂性：浮点数运算依赖硬件指令，很多操作在编译期难以保证跨平台的一致性与可靠性，早期标准出于保守考虑，未将这类数学函数纳入常量表达式范畴。
• 实现难度：不同硬件平台的浮点数格式、行为存在差异，要让nextafter在编译期稳定运行，对编译器的实现要求很高，直到C++26标准才解决这些问题，正式将std::nextafter系列函数标记为constexpr。

内容的提问来源于stack exchange，提问作者Tomáš Nadrchal