编译器如何知道C++常量计算不会触发未定义的行为？

How do compilers know C++ constexpr computations do not trigger undefined behavior?(编译器如何知道C++常量计算不会触发未定义的行为？)

问题描述

C++标准要求编译器在C++常量计算中检查未定义的行为。

在this talk中，Chandler Carruth指出，在检查UB时"您将耗尽检测错误的能力"，而且在一般情况下，检测UB与halting problem相关，因此可以证明无法确定。

他指的不是conexpr中的UB，但conexpr计算从C++14开始就像常规程序一样通用，因此这仍然适用。

那么，当编译器无法确定程序是否是UB程序时，它们会做些什么？他们还会接受这个程序，祈祷自己继续编译吗？或者，他们更加保守，拒绝接受这项计划，即使它可能是正确的？(我个人的感觉是他们这样做)

对我来说，这很重要，因为我用Clang编译得很好的非平凡指针算法进行了常量计算，但用GCC编译失败了，我非常确定这不是UB。你可以说这是一个GCC的错误，但如果UB是无法决定的，那么所有的编译器在这方面都是错误的。

更根本的是，为什么标准要求无UB？有没有技术上的原因？或者更具哲理性的说法("如果编译器不能检查，程序员就会触发UB，就会产生不好的结果")？

我认为这与C++的其余部分不一致，C++的其余部分永远不会阻止您搬起石头砸自己的脚。我宁愿GCC接受我的常量代码并崩溃，或者如果是UB就发出垃圾；而不是当它不知道自己是不是UB时不编译。

正如M.M和Nicol Bolas所指出的，该标准规定了限制(甚至在C++14中)，因此我们永远不会遇到停顿问题类型的UB。然而，我仍然在想，检查UB是否可能太复杂，如果编译器启发式失败，那么他们会(可能不正确地)将其标记为非常量。

但我从评论中感觉到，这更多的是实现不成熟的问题。

推荐答案

在这次演讲中，Chandler Carruth表示，在检查UB时"您将耗尽检测错误的能力"，而且在一般情况下，检测UB与停止问题有关，因此可以证明不可能做出决定。

暂停的问题是，当您获取一个程序并尝试确定该程序在执行时是否一定会暂停。根据定义，停止问题仅将程序视为锁定对象。

持续评估是...评估。您正在执行程序，而不仅仅是查看源代码。

当程序的执行执行某些未定义的操作时，会发生未定义的行为。大多数UB案例不能确定是明确定义的，也不能仅仅通过检查源代码来确定。请考虑以下代码：

void foo(void *ptr)
{
  *reinterpret_cast<int*>(ptr) = 20;
}

那是不是UB？这要视情况而定；如果将指向int的指针传递到foo中，那么它将是定义良好的。此代码是否定义良好只能由执行方式确定。