C++对于浮点数（包括float和其他浮点类型）的行为几乎没有任何限制。这可能导致结果在不同编译器之间或同一编译器的运行时/编译时评估中存在潜在的不一致性。以下是关于此问题的简要总结：
|
在运行时 |
在常量表达式中 |
| 浮点数错误，如除以零 |
未定义行为（UB），但编译器可能通过NaN支持
静默错误作为扩展 |
在常量表达式中是UB，
会导致编译器错误 |
舍入操作，如10.0 / 3.0 |
舍入模式由浮点环境控制；结果可能不同 |
舍入是实现定义的，
结果可能与运行时不同 |
通过-ffast-math和其他编译器优化的语义变化 |
结果可能变得不太精确或更精确；破坏了IEEE-754规范 |
实际上没有影响；最多是实现定义的效果 |
| 调用数学函数 |
错误处理和舍入与+和*的算术相同 |
自C++23起有一些constexpr，
自C++26起有一些constexpr，
在编译时禁止某些错误 |
浮点数错误
某些操作可能会失败，例如除以零。C++标准规定：
如果除法或取模的第二个操作数为零，则行为是未定义的。
- [expr.mul]/4
在常量表达式中，这一规定得到遵守，因此无法通过操作产生NaN，也无法在编译时引发FE_DIVBYZERO异常。
对于浮点数，没有例外。然而，当 std::numeric_limits<float>::is_iec559() 为 true 时，大多数编译器将具备IEEE-754兼容性作为扩展功能。例如，允许除以零，并根据操作数产生无穷大或NaN。
舍入模式
C++始终允许编译时结果与运行时结果之间存在差异。
例如，您可以进行如下求值：
double x = 10.0f / 3.0;
constexpr double y = 10.0 / 3.0;
assert(x == y);
结果可能不总是相同的，因为浮点环境只能在运行时更改，从而可以改变舍入模式。
C++的方法是使浮点环境的效果成为实现定义。它没有提供一种可移植的方式来控制常量表达式中的舍入。
如果使用[FENVC_ACCESS]编译指示符来启用对浮点环境的控制，则本文档不会指定对常量表达式中浮点计算的影响。
-
[cfenv.syn]/Note 1
编译器优化
首先，编译器可能急于优化您的代码，即使这会改变其含义。例如，GCC将优化掉此调用：
const float x = std::sqrt(2);
语义会因为像
-ffast-math这样的标志而发生更大的变化，它允许编译器以一种不符合IEEE-754标准的方式重新排序和优化操作。例如：
float big() { return 1e20f;}
int main() {
std::cout << big() + 3.14f - big();
}
对于IEEE-754浮点数，加法和减法不满足交换律。我们不能将其优化为：(big() - big()) + 3.14f。结果将为0，因为3.14f的精度太小，不足以改变big()的值。然而，启用-ffast-math选项后，结果可以是3.14f。
数学函数
所有操作（包括对数学函数的调用）在运行时与常量表达式可能存在运行时差异。编译时的std::sqrt(2)可能与运行时的std::sqrt(2)不同。然而，这个问题并不局限于数学函数。您可以将这些函数分为以下几类：
无FPENV依赖/非常弱依赖（C++23中的constexpr）[P05333r9]
一些功能完全独立于浮点环境，或者它们根本不会失败，例如：
- `std::ceil`（向上取整）
- `std::fmax`（两个数中的最大值）
- `std::signbit`（获取浮点数的符号位）
此外，还有像 `std::fma` 这样的函数，它只是组合了两个浮点操作。这些函数在编译时与 `+` 和 `*` 没有任何区别。其行为与在 C 中调用这些数学函数相同（参见C23标准的附录 F.8.4），然而，在 C++ 中，如果引发除了 `FE_INEXACT` 以外的异常、设置了 `errno` 等，则它不是一个常量表达式（参见[library.c]/3）。
弱FPENV依赖（自C++26起的constexpr）
[P1383r0]
其他函数依赖于浮点环境，例如std::sqrt或std::sin。然而，这种依赖被称为“弱依赖”，因为它没有明确说明，并且它只存在于浮点数运算本身就是不精确的情况下。
允许在编译时使用+和*，但不允许具有完全相同问题的数学函数是任意的。
数学特殊函数（尚未是constexpr，可能将来会是）
[P1383r0]认为在数学特殊函数中添加constexpr太过雄心勃勃，例如：
std::betastd::riemann_zeta- 以及其他许多...
强FPENV依赖（尚未实现constexpr，可能永远不会）
一些函数如std::nearbyint明确规定使用标准中的当前舍入模式。
这是有问题的，因为您无法使用标准方法在编译时控制浮点环境。
像std::nearbyint这样的函数不是constexpr，可能永远也不会成为。
结论
总结一下，在处理
constexpr数学时，标准委员会和编译器开发人员面临许多挑战。几十年的讨论才解除了某些对
constexpr数学函数的限制，但我们终于取得了成果。这些限制的范围从
std::fabs的任意性到
std::nearbyint的必要性都有所不同。
未来我们可能会看到进一步解除限制，至少对于
数学特殊函数来说是如此。
constexpr处理。 - BoPconstexpr化。 - BoPconstexpr处理。 - undefinedconst（或constexpr）如何改变结果：https://stackoverflow.com/q/75859098/7325599 - Fedor