c++ - 将非 constexpr 标准库函数视为 constexpr 是否符合编译器扩展？

Question

gcc 编译下面的代码没有警告:

#include <cmath>

struct foo {
  static constexpr double a = std::cos(3.);
  static constexpr double c = std::exp(3.);
  static constexpr double d = std::log(3.);
  static constexpr double e1 = std::asin(1.);
  static constexpr double h = std::sqrt(.1);
  static constexpr double p = std::pow(1.3,-0.75);
};

int main()
{
}

上面使用的标准库函数都不是constexpr 函数，我们可以在两个the draft C++11 standard 都需要常量表达式 的地方使用它们。和 draft C++14 standard 7.1.5 部分 [dcl.constexpr]:

[...]If it is initialized by a constructor call, that call shall be a constant expression (5.19). Otherwise, or if a constexpr specifier is used in a reference declaration, every full expression that appears in its initializer shall be a constant expression.[...]

即使使用 -std=c++14 -pedantic 或 -std=c++11 -pedantic 也不会生成警告 ( see it live )。使用 -fno-builtin 会产生错误 ( see it live )，这表明 builtin这些标准库函数的版本被视为 constexpr

而 clang 不允许带有我尝试过的任何标志组合的代码。

所以这是一个 gcc 扩展，将至少一些内置函数视为 constexpr 函数，即使标准没有明确要求它们。我本来希望至少在严格一致性模式下收到警告，这是一个符合标准的扩展吗？

Answer 1

TL;DR

在 C++14 中，这是明确不允许的，尽管在 2011 中，这种情况似乎是明确允许的。尚不清楚对于 C++11，这是否属于 as-if rule。 ，我不相信它会改变可观察到的行为，但我在下面引用的问题中没有阐明这一点。

详情

这个问题的答案随着 LWG issue 2013 的发展而改变。打开:

Suppose that a particular function is not tagged as constexpr in the standard, but that, in some particular implementation, it is possible to write it within the constexpr constraints. If an implementer tags such a function as constexpr, is that a violation of the standard or is it a conforming extension?

在 C++11 中，不清楚 as-if 规则 是否允许这样做，但原始提案一旦被接受就会明确允许这样做，我们可以在下面的 gcc 错误报告中看到 I引用，这是gcc团队的假设。

在 2012 年达成的共识发生了变化，提案也发生了变化，在 C++14 中这是一个不符合标准的扩展。这反射(reflect)在草案 C++14 标准部分 17.6.5.6 [constexpr.functions] 中说:

[...]An implementation shall not declare any standard library function signature as constexpr except for those where it is explicitly required.[..]

虽然严格阅读这一点似乎为隐式处理内置函数留下了一些回旋余地，就好像它是一个 constexpr 我们可以从问题中的以下引用中看出，其目的是防止实现中的分歧，因为相同的代码可以使用 SFINAE 时会产生不同的行为(强调我的):

Some concern expressed when presented to full committee for the vote to WP status that this issue had been resolved without sufficient thought of the consequences for diverging library implementations, as users may use SFINAE to observe different behavior from otherwise identical code.

我们可以从 gcc 错误报告中看到 [C++0x] sinh vs asinh vs constexpr团队依赖于较早提出的 LWG 2013 的决议其中说:

[...]Additionally, an implementation may declare any function to be constexpr if that function's definition satisfies the necessary constraints[...]

在决定在严格一致性模式下是否允许对数学函数进行此更改时。

据我所知，如果我们在严格一致性模式下收到警告，即使用 -std=c++11 -pedantic 或在此模式下禁用它，这将变得符合要求。

请注意，我在错误报告中添加了一条注释，说明自从最初解决了这个问题后，解决方案发生了变化。

乔纳森·韦克利 pointed out在另一个问题中更新了 discussion并且似乎很可能会重新打开 gcc 错误报告以解决此一致性问题。

内在函数呢

Compiler intrinsics标准未涵盖，据我所知，它们应该不受此规则的约束，因此使用:

static constexpr double a = __builtin_cos(3.);

应该被允许。这个问题出现在错误报告中，Daniel Krügler 的意见是:

[...]Library functions and other intrinsics can probably be considered as exceptions, because they are not required to be "explainable" by normal language rules.