未定义的行为值得吗？

Question

由于未定义的行为，许多糟糕的事情发生并继续发生（或者不发生，谁知道，任何事情都可能发生）。据我所知，引入这一点是为了给编译器优化留下一些回旋余地，也许也是为了使 C++ 更容易移植到不同的平台和体系结构。然而，由未定义行为引起的问题似乎太大，无法通过这些论点来证明其合理性。未定义行为的其他论点是什么？如果没有，为什么未定义的行为仍然存在？

编辑 为我的问题添加一些动机：由于与不太熟练的 C++ 同事的几次不好的经历，我已经习惯了让我的代码尽可能安全。断言每一个论点、严格的常量正确性等等。我尽量不留有可能以错误方式使用我的代码的空间，因为经验表明，如果存在漏洞，人们就会使用它们，然后他们会打电话给我，说我的代码很糟糕。我认为让我的代码尽可能安全是一个很好的做法。这就是为什么我不明白为什么存在未定义的行为。有人可以给我一个在运行时或编译时无法检测到的未定义行为的示例吗？

Answer 1

我认为关注的核心来自于 C/C++ 速度至上的哲学。

这些语言是在原始能力匮乏的时候创建的，你需要尽可能地进行所有优化才能获得可用的东西。

指定如何处理 UB 意味着首先检测它，然后当然指定正确的处理方法。然而检测它违背了语言的速度第一哲学！

今天，我们还需要快速程序吗？是的，对于我们这些资源非常有限（嵌入式系统）或限制非常严格（响应时间或每秒事务数）的人来说，我们确实需要尽可能多地挤出资源。

我知道这句座右铭：用更多的硬件来解决问题。我工作的地方有一个应用程序：

• 预计得到答复的时间？不到 100 毫秒，中间有数据库调用（感谢 memcached）。
• 每秒交易数量？平均1200，峰值1500/1700。

它运行在大约 40 个怪物上：8 个双核 opteron (2800MHz) 和 32GB RAM。此时，使用更多的硬件很难变得“更快”，因此我们需要优化的代码，以及允许它的语言（我们确实限制在其中添加汇编代码）。

我必须说，无论如何，我不太关心UB。如果您的程序调用了 UB，那么它需要修复实际发生的任何行为。当然，如果立即报告，修复它们会更容易：这就是调试版本的用途。

因此，也许我们不应该关注 UB，而是应该学习使用这种语言：

• 不要使用未经检查的调用
• （对于专家） 不要使用未经检查的调用
• （对于专家） 你确定你真的需要这里未经检查的调用吗？

一切都突然变得更好:)

Answer 2

我对未定义行为的看法是：

标准定义了如何使用语言，以及以正确的方式使用时实现应该如何反应。然而，涵盖每个功能的所有可能用途将需要大量工作，因此标准仅此而已。

然而，在编译器实现中，你不能只是“就这样”，代码必须转换成机器指令，而且不能只留下空白。在许多情况下，编译器可能会抛出错误，但这并不总是可行：在某些情况下，需要额外的工作来检查程序员是否做错了事情（例如：调用析构函数两次——以检测到这一点） ，编译器必须计算某些函数被调用的次数，或者添加额外的状态，等等）。因此，如果标准没有定义它，而编译器只是让它发生，那么有时会发生有趣的事情，如果你不走运的话。

Answer 3

这些问题不是由未定义的行为引起的，而是由编写导致该行为的代码引起的。答案很简单 - 不要编写那种代码 - 不这样做并不完全是火箭科学。

至于：

未定义行为的示例
无法在运行时检测到或
编译时间没有相当多
开销

一个现实世界的问题：

int * p = new int;
// call loads of stuff which may create an alias to p called q
delete p;

// call more stuff, somewhere in which you do:
delete q;

在编译时检测到这一点是不可能的。在运行时，这只是极其困难的，并且需要内存分配系统比我们简单地说第二个删除未定义的情况进行更多的簿记（即更慢并占用更多内存）。如果您不喜欢这个，也许 C++ 不适合您 - 为什么不切换到 java？

Answer 4

未定义行为的主要来源是指针，这就是 C 和 C++ 有大量未定义行为的原因。

考虑这段代码：

char * r = 0x012345ff;
std::cout << r;

这段代码看起来很糟糕，但是它应该发出错误吗？如果该地址确实可读，即它是我以某种方式获得的值（可能是设备地址等）怎么办？

在这种情况下，无法知道该操作是否合法，如果不合法，其行为确实是不可预测的。

除此之外：一般来说，C++ 的设计考虑了“零开销规则”（请参阅​​ C++ 的设计和演进），因此它不可能对检查极端情况等的实现施加任何负担。您应该始终记住，这种语言的设计和确实不仅在桌面上使用，而且在桌面上使用。在资源有限的嵌入式系统中也是如此。

Answer 5

许多被定义为未定义行为的事情将很难通过编译器或运行时环境进行诊断，即使不是不可能。

那些简单的行为已经变成了定义-未定义的行为。考虑调用纯虚方法：这是未定义的行为，但大多数编译器/运行时环境都会提供相同术语的错误：调用了纯虚方法。事实上的标准是，在我所知道的所有环境中，调用纯虚方法调用都是运行时错误。

Answer 6

该标准未定义“某些”行为，以便允许多种实现，而不会给这些实现带来检测“某些”情况的开销，也不会给程序员带来防止首先出现这些情况所需的约束。

曾经有一段时间，对于大量项目来说，避免这种开销是 C 和 C++ 的主要优势。

现在的计算机比发明 C 语言时快了数千倍，并且诸如始终检查数组边界或使用几兆字节的代码来实现沙盒运行时之类的开销对于大多数项目。此外，由于我们的程序每秒处理许多兆字节的潜在恶意数据，（例如）缓冲区溢出的成本增加了几个因素。

因此，令人有些沮丧的是，没有一种语言具有 C++ 的所有有用功能，并且还具有定义每个编译程序的行为（受特定于实现的行为影响）的属性。但只是有一点——在 Java 中编写行为如此令人困惑的代码实际上并不那么困难，以至于从调试的角度来看，如果不是安全的话，它也可能是未定义的。编写不安全的 Java 代码也并不困难 - 只是不安全通常仅限于泄露敏感信息或授予对应用程序不正确的权限，而不是放弃对运行 JVM 的操作系统进程的完全控制

。我认为优秀的软件工程需要所有语言的纪律，区别在于当我们的纪律失败时会发生什么，以及我们对其他语言（在性能和占用空间以及您喜欢的 C++ 功能方面）收取多少费用以防止这种情况发生。如果其他语言提供的保险对于您的项目来说是值得的，那就接受吧。如果 C++ 提供的功能值得冒着未定义行为的风险而付出代价，那么就选择 C++。我不认为试图争论 C++ 的好处是否“证明”其成本是合理的，就好像它是一个对每个人都一样的全球财产一样。它们在 C++ 语言设计的职权范围内是合理的，即您不必为不使用的东西付费。因此，正确的程序不应该变慢，以便不正确的程序得到有用的错误消息而不是 UB，并且大多数情况下都会在异常情况下表现（例如 32- 的<<32）如果需要在委员会希望“有效”支持 C++ 的硬件上显式检查异常情况，则不应定义（例如，结果为 0）。

再看另一个例子：我认为英特尔专业 C 和 C++ 编译器的性能优势不足以证明购买它的成本是合理的。因此，我没有购买它。并不意味着其他人会做出与我相同的计算，也不意味着我将来也会始终进行相同的计算。

Answer 7

编译器和编程语言是我最喜欢的主题之一。过去我做过一些与编译器相关的研究，并且多次发现未定义的行为。

C++和Java非常流行。这并不意味着他们有出色的设计。它们之所以被广泛使用，是因为它们冒着损害设计质量的风险只是为了获得认可。 Java追求垃圾收集、虚拟机和无指针外观。他们是部分先驱者，无法从以前的许多项目中学习。

就 C++ 而言，主要目标之一是为 C 用户提供面向对象的编程。即使是 C 程序也应该使用 C++ 编译器进行编译。这造成了很多令人讨厌的开放点，而 C 已经有很多含糊之处。 C++ 强调的是力量和流行度，而不是完整性。没有多少语言可以提供多重继承，C++ 可以提​​供多重继承，尽管不是以一种非常完美的方式。未定义的行为将始终存在以支持其荣耀和向后兼容性。

如果你真的想要一种健壮且定义良好的语言，你必须寻找其他地方。遗憾的是，这并不是大多数人主要关心的问题。例如，Ada 是一种很棒的语言，其中清晰定义的行为很重要，但由于其用户基础狭窄，几乎没有人关心该语言。我对这个例子有偏见，因为我真的很喜欢这种语言，我在我的博客上发布了一些内容 但如果您想了解更多有关语言定义如何帮助减少错误的信息，甚至在编译之前，请查看 这些幻灯片

我并不是说 C++ 是一种糟糕的语言！它只是有不同的目标，我喜欢与之合作。您还拥有大型社区、出色的工具以及更多出色的东西，例如 STL、Boost 和 QT。但你的怀疑也是成为一名伟大的C++程序员的根源。如果您想精通 C++，这应该是您关心的问题之一。我鼓励您阅读前面的幻灯片以及这位评论家。当语言没有达到你的预期时，它将对你理解有很大帮助。

顺便说一下。未定义的行为完全违背可移植性。例如，在 Ada 中，您可以控制数据结构的布局（在 C 和 C++ 中，它可以根据机器和编译器进行更改）。线程是语言的一部分。所以移植C和C++软件会给你带来更多的痛苦而不是快乐

Answer 8

明确未定义行为和实现定义行为之间的差异非常重要。实现定义的行为使编译器编写者有机会向语言添加扩展以利用其平台。为了编写在现实世界中运行的代码，这样的扩展是必要的。

另一方面，UB 存在于在不对语言进行重大更改或与 C 语言进行重大差异的情况下很难或不可能设计解决方案的情况。一个例子取自 BS 讨论此问题的页面是：

int a[10];
a[100] = 0; // range error
int* p = a;
// ...
p[100] = 0; // range error (unless we gave p a better value before that assignment)

范围错误为 UB。这是一个错误，但标准未定义平台应如何精确地处理此问题，因为标准无法定义它。每个平台都不同。它不能被设计为错误，因为这需要在语言中包括自动范围检查，这将需要对语言的功能集进行重大更改。对于语言来说，无论是在编译时还是运行时，p[100] = 0 错误都更难以生成诊断，因为编译器无法知道 p< /code> 确实指向没有运行时支持。

Answer 9

几年前我也问过自己同样的问题。当我试图为写入空指针的函数的行为提供正确的定义时，我立即停止考虑它。

并非所有设备都有受保护内存的概念。因此，您不可能依靠系统通过段错误或类似情况来保护您。并非所有设备都具有只读内存，因此您不能说写入根本不执行任何操作。我能想到的唯一其他选择是要求应用程序在没有系统帮助的情况下引发异常[或中止，或其他]。但在这种情况下，编译器必须在每次内存写入之前插入代码以检查 null ，除非它可以保证自列表内存写入以来指针没有更改。这显然是不可接受的。

因此，保留行为未定义是我能做出的唯一合乎逻辑的决定，无需说“兼容的 C++ 编译器只能在具有受保护内存的平台上实现”。

Answer 10

这是我最喜欢的：在使用它对非空指针进行delete（不仅取消引用，而且还castin等）之后就是UB（请参阅这个问题）。

如何遇到 UB：

{
    char* pointer = new char[10];
    delete[] pointer;
    // some other code
    printf( "deleted %x\n", pointer );
}

现在我知道上面的代码在所有架构上都可以正常运行。教导编译器或运行时执行此类情况的分析非常困难且昂贵。不要忘记，有时在删除和使用指针之间可能有数百万行代码。在删除后立即将设置指针设置为 null 的成本可能很高，因此它也不是通用的解决方案。

这就是为什么有UB的概念。您不希望代码中出现 UB。也许有效也许无效。在这个实现上工作，在另一个实现上中断。

Answer 11

有时，未定义的行为是好的。以一个大整数为例。

<代码>

union BitInt
{
    __int64 Whole;
    struct
    {
        int Upper;
        int Lower; // or maybe it's lower upper. Depends on architecture
    } Parts;
};

规范规定，如果我们最后读取或写入整体，则从部分读取/写入是未定义的。

现在，这对我来说有点愚蠢，因为如果我们无法触及工会的任何其他部分，那么一开始就没有任何意义，对吧？

但无论如何，也许某些函数将采用 __int64，而其他函数则采用两个单独的整数。我们可以使用这个联合，而不是每次都进行转换。我所知道的每个编译器都会以非常清晰的方式处理这种未定义的行为。所以在我看来，未定义的行为在这里并没有那么糟糕。