为什么**不**声明一个函数`constexpr`？ [英] Why **not** to declare a function `constexpr`?

问题描述

由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
会造成任何损害吗？

---

p>

即使没有好的理由永远声明一个函数
不是 constexpr 我可以想象， constexpr 关键字有一个
过渡角色：它在代码中不存在，不需要编译时
评估将允许编译器不实现编译时
评估仍然编译该代码（但在代码
上可靠地失败，需要通过使用 constexpr ）使它们成为展示。

但是我不明白：如果没有好的理由
永远声明一个函数不是 constexpr ，为什么不是每个函数
在标准库中声明 constexpr ？ （你不能争辩
它尚未完成，因为没有足够的时间到
做它，因为做全部是一个没有脑子 - 相反如果要使它 constexpr 或者不是。）
---我知道 N2976
故意不需要许多标准库类型的cstrs，例如
容器，因为这将是太限制可能的
实现。让我们从参数中排除它们，只是想知道：
一旦标准库中的类型实际上有一个 constexpr cstr，为什么不是
每个函数操作它声明 constexpr ？

在大多数情况下，你也不能说你可能不喜欢声明一个函数
constexpr 只是因为你不设想任何编译时使用：
因为如果其他evtl。会使用你的代码，他们可能会看到这样的使用
你不会。 （但是，对类型trait类型和类似的东西，当然。）

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

（每个函数我总是意味着：每个函数满足
要求为 constexpr ，即定义为单个
返回语句，只接受带有constexpr
类型的参数，并且只调用 constexpr 函数。）

问题 std :: forward discard constexpr -ness？
constexpr 如果他们遵守的规则constexpr ---没有动态转换，没有内存分配，没有调用非 - constexpr 函数等

在标准库中声明一个函数 constexpr 所有实现服从这些规则。

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

其次，这是一个很大的约束的实现，并将取缔许多调试实现。因此，如果效益超过成本，或者需求足够紧，以至于实现几乎不得不服从 constexpr 规则，那么它是值得的。对每个功能进行这种评估也是一项长期的工作。

Any function that consists of a return statement only could be declared constexpr and thus will allow to be evaluated at compile time if all arguments are constexpr and only constexpr functions are called in its body. Is there any reason why not to declare any such function constexpr ?

Example:

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

Could anyone provide an example where declaring a function constexpr would do any harm?

---

Some initial thoughts:

Even if there should be no good reason for ever declaring a function not constexpr I could imagine that the constexpr keyword has a transitional role: its absence in code that does not need compile-time evaluations would allow compilers that do not implement compile-time evaluations still to compile that code (but to fail reliably on code that needs them as made explict by using constexpr).

But what I do not understand: if there should be no good reason for ever declaring a function not constexpr, why is not every function in the standard library declared constexpr? (You cannot argue that it is not done yet because there was not sufficient time yet to do it, because doing it for all is a no-brainer -- contrary to deciding for every single function if to make it constexpr or not.) --- I am aware that N2976 deliberately not requires cstrs for many standard library types such as the containers as this would be too limitating for possible implementations. Lets exclude them from the argument and just wonder: once a type in the standard library actually has a constexpr cstr, why is not every function operating on it declared constexpr?

In most cases you also cannot argue that you may prefer not to declare a function constexpr simply because you do not envisage any compile-time usage: because if others evtl. will use your code, they may see such a use that you do not. (But granted for type trait types and stuff alike, of course.)

So I guess there must be a good reason and a good example for deliberately not declaring a function constexpr?

(with "every function" I always mean: every function that meets the requirements for being constexpr, i.e., is defined as a single return statement, takes only arguments of types with constexpr cstrs and calls only constexpr functions.)

The question Why does std::forward discard constexpr-ness? is a special case of this one.

解决方案

Functions can only be declared constexpr if they obey the rules for constexpr --- no dynamic casts, no memory allocation, no calls to non-constexpr functions, etc.

Declaring a function in the standard library as constexpr requires that ALL implementations obey those rules.

Firstly, this requires checking for each function that it can be implemented as constexpr, which is a long job.

Secondly, this is a big constraint on the implementations, and will outlaw many debugging implementations. It is therefore only worth it if the benefits outweigh the costs, or the requirements are sufficiently tight that the implementation pretty much has to obey the constexpr rules anyway. Making this evaluation for each function is again a long job.

这篇关于为什么**不**声明一个函数`constexpr`？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！