为什么**不**将函数声明为`constexpr`？答案

【问题标题】：Whyever **not** declare a function to be `constexpr`?为什么**不**将函数声明为`constexpr`？
【发布时间】：2026-02-24 11:50:01
【问题描述】：

任何只包含 return 语句的函数都可以被声明 constexpr 因此将允许在编译时进行评估，如果所有参数是constexpr，并且只有constexpr 函数在其主体中被调用。 有什么理由不声明任何这样的功能constexpr？

例子：

  constexpr int sum(int x, int y) { return x + y; }
  constexpr i = 10;
  static_assert(sum(i, 13) == 23, "sum correct");

谁能提供一个声明函数constexpr的例子会造成什么伤害吗？

一些初步的想法：

即使没有充分的理由去声明一个函数不是constexpr 我可以想象constexpr 关键字有一个过渡角色：它在不需要编译时的代码中不存在评估将允许不实现编译时的编译器评估仍然编译该代码（但在代码上可靠地失败这需要它们，通过使用constexpr 进行明确说明。

但我不明白的是：如果没有充分的理由曾经声明一个函数不是 constexpr，为什么不是 every 函数在标准库中声明 constexpr? （你不能争论还没有完成，因为还没有足够的时间这样做，因为为 all 做这件事是不费吹灰之力的——这与为每个单独的功能决定是否使其成为 constexpr 相反。） --- 我知道N2976 故意不需要 cstrs 用于许多标准库类型，例如作为容器，因为这对可能的限制太大了实施。让我们将它们排除在论点之外，只是想知道：一旦标准库中的一个类型实际上有一个constexpr cstr，为什么不是每个对其操作的函数都声明为constexpr？

在大多数情况下，您也不能争辩说您可能不喜欢声明函数 constexpr 仅仅是因为您没有设想任何编译时使用：因为如果其他人 evtl.将使用您的代码，他们可能会看到您没有看到的这种用法。（当然，对于类型特征类型和类似的东西是允许的。）

所以我想故意不声明函数constexpr一定有充分的理由和很好的例子？

(对于“每个功能”，我总是指：满足要求为constexpr，即定义为单个 return 语句，只接受带有 constexpr 类型的参数 cstrs 并仅调用 constexpr 函数。由于 C++14，much more is allowed in the body of such function：例如，C++14 constexpr 函数可以使用局部变量和循环，因此可以声明更广泛的函数类constexpr。）

问题Why does std::forward discard constexpr-ness? 是这个问题的一个特例。

【问题讨论】：

我的问题是：声明为 constexpr 但调用时不会导致常量表达式的函数会发生什么，应该是编译错误不是吗？那么对于那些不是特别旨在仅在编译时进行评估的函数，它们不应该被声明为 constexpr 吗？
我搜索了标准并且找不到关于如果 constexpr 函数被非常量表达式参数调用会发生什么的提示。无论如何，如果这是错误的，那么 std::forward 的情况也很清楚，如果你定义了 std::forward constexpr，那么它必须用作 constexpr 并且不能转发普通变量。
@user534498 我也找不到标准中的位置。但是唯一有意义的事情（以及 g++ 的实际作用）是在使用非 constexp 参数调用 constexpr 函数时默默地忽略 constexpr。否则，std::bitset 中的 size 之类的函数显然无法成为 constexpr。
@Lars：不仅如此，我还注意到，如果输出不是明确的constexpr，g++ 会忽略constexpr，无论输入是否是。虽然我不确定这是否是标准的意图，但这对我来说没有任何意义。例如，将constexpr 函数的返回值分配给const int 将导致该函数出现在二进制文件中并被执行，而将其分配给enum（具有相同的输入！）只是定义了一个枚举值和根本不生成代码。

标签： c++ c++11 constants constexpr function-declaration

【解决方案1】：

只有遵守constexpr 规则的函数才能声明为constexpr --- 没有动态转换、没有内存分配、没有调用非constexpr 函数等。

将标准库中的函数声明为constexpr 要求所有实现都遵守这些规则。

首先，这需要检查每个可以实现为constexpr的函数，这是一项漫长的工作。

其次，这对实现是一个很大的限制，并且会禁止许多调试实现。因此，只有当收益超过成本，或者要求足够严格以至于实现几乎必须遵守constexpr 规则时，它才是值得的。对每个函数进行这种评估又是一项漫长的工作。

【讨论】：

我无意批评图书馆工作组的工作，如果我的问题听起来像这样，我很抱歉。你所说的与接口有关，你是对的，标准库描述了这样一个具有许多实现的接口。所以EVT。调查 STL 以指导 constexpr 的使用对我来说并不聪明。我的问题是关于实现的。您是否同意 implementations 应尽可能为 constexpr ？或者是否有不是 constexpr 的实现示例？（对不起，evtl。我没有明白你的意思......）
制作constexpr 的东西非常受限制。这不是我会轻易做的事情，因为一旦它成为您界面的一部分，由于向后兼容性问题，很难更改它。即使对于标准库的给定实现，这也适用 --- 许多人会不知不觉地依赖他们使用的库的实现属性，所以我不希望实现除了标准要求的功能之外，还可以创建任何功能constexpr，或者没有合理的实现会违反约束。
嗨！不好意思，还是没看懂，能给个代码例子吗？如果我们在一个函数中声明 constexpr 并且在编译器评估之后这可能是也可能不是 constexpr，那么为什么不在每个可能以这种方式编译的函数中声明它（如果我们希望在编译时运行比在运行时运行更多）？
首先，constexpr 函数隐含为inline，因此如果您不想将函数定义放在头文件中，则它们不能是constexpr。其次，声明函数constexpr意味着你不能使用try块、static变量、thread_local变量或非文字类型的变量，所以不能使用std::string或std::vector等。
如果您有一个可能是 constexpr 的 inline 函数，那么声明它没有任何不利之处，只是它可能会限制您的未来 --- 将实现更改为不成为constexpr-compatible 将是一个 ABI 中断，因为在您的代码中的某处可能会在常量表达式中使用它。

【解决方案2】：

我认为您所指的是partial evaluation。您要说的是，某些程序可以分为两部分-需要运行时信息的部分，以及无需任何运行时信息即可完成的部分-理论上您可以完全评估程序的一部分在您开始运行程序之前，它不需要任何运行时信息。有一些编程语言可以做到这一点。例如，D 编程语言在编译器中内置了一个解释器，可以让您在编译时执行代码，前提是它满足某些限制。

让部分评估发挥作用存在一些主要挑战。首先，它极大地复杂化了编译器的逻辑，因为编译器需要能够模拟所有可以在编译时放入可执行程序的操作。在最坏的情况下，这需要您在编译器内部拥有一个完整的解释器，这会导致难题（编写一个好的 C++ 编译器）并使其难以完成。

我相信目前关于constexpr 的规范的原因仅仅是为了限制编译器的复杂性。它仅限于检查的情况相当简单。无需在编译器中实现循环（这可能会导致其他一系列问题，例如如果您在编译器中获得无限循环会发生什么）。它还避免了编译器可能不得不在运行时评估可能导致段错误的语句，例如跟随一个错误的指针。

要记住的另一个注意事项是某些功能有副作用，例如从cin 读取或打开网络连接。像这样的函数根本无法在编译时进行优化，因为这样做需要仅在运行时可用的知识。

总而言之，理论上没有理由不能在编译时对 C++ 程序进行部分评估。事实上，人们一直都在这样做。例如，优化编译器本质上是尽可能多地尝试这样做的程序。模板元编程是 C++ 程序员尝试在编译器中执行代码的一个实例，部分原因是模板规则形成了一种函数式语言，编译器更容易实现这种语言，因此可以使用模板做一些很棒的事情。此外，如果您考虑编译器作者时间和编程时间之间的权衡，模板元编程表明，如果您可以让程序员向后弯腰以获得他们想要的东西，您可以构建一个非常弱的语言（模板系统）并保持语言复杂简单。（我说“弱”是指“不是特别有表现力”，而不是可计算性理论意义上的“弱”）。

希望这会有所帮助！

【讨论】：

规则似乎没有禁止副作用。
虽然是一个非常有趣的答案（部分评估是一个很大的话题，每个编译器编写者都尝试过），但似乎有点离题，因为问题更多是关于 @ 的使用987654324@（对于程序员）似乎比它的效果。
我宁愿你离开这篇文章，这很有趣。例如，我不知道 D 嵌入了一个解释器 :) 我必须承认我对 constexpr 的要求有点模糊，我需要继续努力。
@Matthieu M. 感谢您提供的信息。对我来说，关于 D 的事情也是新鲜有趣的。但是 Matthieu 是对的，你回答了这个问题：为什么 constexpr 仅限于由单个 return 语句组成的函数？虽然我的问题是：我们现在是否必须声明每个函数 constexpr 或者是否有任何情况会产生负面影响？（但请留下你的答案！）
这是一个非常有用的答案，我同意您的观点，即 TMP 提供了一种非常好的纯函数式语言。虽然，constexpr 也允许编写纯函数式代码，同时在运行时和编译时变量之间提供了一个很好的桥梁。但是，没有像 std::find 和其他一些定义 constexpr 这样的函数似乎人为地限制了可以使用 STL 编写的纯代码的种类。

【解决方案3】：

如果函数有副作用，你不会想标记它constexpr。 Example

我无法从中得到任何意想不到的结果，实际上它看起来像gcc 4.5.1 just ignores constexpr

【讨论】：

在您的示例中，f 在非 constexpr 变量 g 上调用 operator++，因此不是有效的 constexpr 函数。 g++ (snapshot 2011-02-19) 正确抛出错误信息：“g is not a constant expression”。
@Lars：我多次阅读标准（草案 3225）的[dcl.constexpr] 部分，但找不到任何阻止此功能成为constexpr 的内容，因为文本“表达式 是一个潜在的常量表达式”已被删除。
“示例”链接已失效，ideone 显示“未找到解决方案”
@AlexanderMalakhov：向 ideone 报告。他们的常见问题解答保证代码“永远”可用：ideone.com/faq 我不再使用该网站，因为他们删除了内容，没有警告，并且违反了他们自己的条款。
我并不是说这是你的错 :) 但也许你记得那段代码并且可以在这里重现它？