从语言设计层面来看，当编译时无法推断条件时，为什么"if constexpr"不衰减到"trival if"

From LANGUAGE DESIGN level, why doesn't "if constexpr" decay to "trival if" when condition cannot be deduced at compile-time

本文关键字：if 条件 trival 为什么 constexpr 衰减 语言 编译      更新时间：2023-10-16

我们知道，当constexpr function的返回值不能在compile-time时知道时，它会延迟计算到run-time(IOW，衰减到non-constexpr function(。这使我们能够自由地constexpr功能，而不必担心任何开销。

我认为它也可以适用于if statement.从 c++17 开始，我们有if constexpr，所以我们可以轻松使用compile-time if statement(无需true_type/false_type。然而，与constexpr function不同的是，如果在编译时无法知道其条件，它将失败：

constexpr int factorial(int n)
{
if constexpr(n == 0) return 1;
else return n * factorial(n-1);
}

因此，上面的代码无法通过编译，因为n不是常量表达式。但可以肯定的是，当输入在编译时已知时，可以在compile-time时计算该函数。

出于同样的原因，吞下错误/异常并只是耕耘是不好的。它可能会使您的程序处于某种未指定的状态。几乎无法推理。

如果不满足程序中的约束，则需要立即通知编写并依赖它的人。使这样的事情成为语言结构的硬错误是有道理的。特别是如果语言结构驱动代码的实际生成。

在这种情况下，约束b为有效的常量表达式。

相关文章：