由于未定义行为的存在，许多糟糕的事情已经发生并且仍在发生（或者没有发生，谁知道呢，一切皆有可能）。我理解这是为了给编译器留下一些灵活性以进行优化，也可能是为了使C ++更容易移植到不同的平台和架构。然而，由未定义行为引起的问题似乎过于严重，无法通过这些论点来证明其合理性。还有其他关于未定义行为的论点吗？如果没有，为什么未定义行为仍然存在？
编辑：为我的问题添加一些动机：由于与不那么精通C ++的同事发生了几次不愉快的经历，我已经开始习惯尽可能地使我的代码更加安全。对每个参数进行断言、坚定的const正确性等等。我试图留下尽可能少的空间来使用我的代码方式错误，因为经验表明，如果有漏洞，人们将利用它们，然后他们会指责我的代码质量差。我认为使我的代码尽可能安全是一个好的实践。这就是为什么我不理解为什么会出现未定义行为。请问能否举个例子，说明不能在运行时或编译时检测到的未定义行为，而不带来相当大的开销？
我认为人们对 C/C++ 的关注点在于速度高于一切的哲学。
这些语言是在计算能力非常有限的时代创建的，你需要尽可能地进行优化才能得到可用的东西。
指定如何处理未定义行为将意味着首先检测它，然后当然要指定正确的处理方式。但是，检测它违反了语言的速度优先哲学！
今天，我们是否仍需要快速的程序？对于我们中那些使用非常有限资源（嵌入式系统）或面临非常严苛约束（响应时间或每秒事务数）的人来说，我们确实需要尽可能多地挤出性能。
我知道“将问题扔给更多硬件”这样的座右铭。我们在工作中有一个应用：
它在大约40个巨兽上运行：8个双核心opteron（2800MHz）和32GB的RAM。此时更多硬件变得困难，因此我们需要优化的代码和允许优化的语言（我们限制了在其中添加汇编代码）。
我必须说，我并不太关心未定义行为。如果您的程序调用 UB，则需要修复实际发生的任何行为。当然，如果立即报告它，那么修复它将更容易：这就是调试版本的作用。
因此，也许我们应该学会使用语言，而不是专注于未定义行为：
一切都变得更好了 :)
关于未定义行为，我的看法是：
标准规定了语言的使用方式以及实现在正确使用时应该如何反应。然而，覆盖所有功能的每种可能使用方式将需要大量工作，因此标准只能止步于此。
然而，在编译器实现中，你不能仅仅“止步于此”，代码必须转换为机器指令，不能留下空白。在许多情况下，编译器可以抛出错误，但这并不总是可行的：有些情况下，检查程序员是否做错了事情需要额外的工作（例如：调用析构函数两次 - 要检测这一点，编译器必须统计某些函数被调用的次数，或者添加额外的状态等）。因此，如果标准没有定义，而编译器却让它发生，那么不幸的时候可能会发生一些巧妙的事情。
[]。如果您想要受检访问，则使用.at（）。它们都在标准中。 - David Thornley[]的惯用方式... 因此，我更喜欢有一种安全的惯用方式，以及一种不安全但更快速的方式供那些真正需要速度的人使用。 - Matthieu M.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;
在编译时检测这个问题是不可能的。在运行时，它仅仅是非常困难，需要内存分配系统进行更多的簿记（即更慢，占用更多的内存），而如果我们只是说第二个 delete 是未定义的，那么情况就不同了。如果你不喜欢这样，也许 C++ 不是适合你的语言-为什么不转换到 Java 呢？
*p，您都必须验证 p 是否是指向有效内存块的指针，这需要运行时跟踪所有分配的内存以进行检查。 - David Rodríguez - dribeas未定义行为的主要来源是指针，这就是为什么C和C++有很多未定义行为的原因。
考虑以下代码：
char * r = 0x012345ff;
std::cout << r;
许多被定义为未定义行为的事情，如果不是不可能，也很难通过编译器或运行时环境进行诊断。
那些容易的已经变成了定义-未定义行为。考虑调用一个纯虚方法：这是未定义的行为，但大多数编译器/运行时环境都会以相同的术语提供错误：调用了纯虚函数。在我所知道的所有环境中，调用纯虚方法调用是运行时错误的事实标准。
streambuf内部怎么办？消息必须是英文的还是可以本地化的？最致命的是：我的应用程序用户无论如何都不会理解它。 - MSaltersstd::terminate，您并没有真正帮助解决问题，因为终止处理程序可以由用户设置，并且它没有任何手段来知道什么导致系统调用terminate。 - David Rodríguez - dribeasterminate。定义一个特定的行为的问题在于，您不允许提供不同更好的行为。正如您已经说的，未定义只意味着当没有其他保证时才为未定义。 - David Rodríguez - dribeasint 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)
p[100] = 0 错误对于语言来说也更加难以生成诊断，因为编译器无法在没有运行时支持的情况下知道 p 实际指向什么。arr结尾，符合标准的编译器是否可以将任何形式为arr[i]的引用替换为arr[0]？ 我不知道单元素数组是否足够常见，值得开发利用，但是代码arr[0]肯定比arr[i]的代码更快更紧凑。我的猜测是，对于i！= 0，即使在结构之外分配存储空间，arr[i]也会是未定义行为，但是即使结构黑客不合法，它也很常见，因此编译器应该适应它。 - supercat行为，如可能在使用错误的程序结构或错误的数据时发生，对此国际标准没有任何要求。[...] [注意：允许的未定义行为范围从完全忽略该情况并产生不可预测的结果，到在环境中具有特定文档方式的翻译或程序执行时表现出相应行为[...] —结束备注 ] - Sebastian Machunsigned char ch = getchar(); if (ch < 216) printf("Hey"); ch*=(ch*ch*ch*ch);，超现代哲学认为，能够从最后一个语句推断出ch将小于216（因此printf应始终执行）的价值超过了让代码对所有ch值执行模256算术的价值。 - supercat{
char* pointer = new char[10];
delete[] pointer;
// some other code
printf( "deleted %x\n", pointer );
}
现在，在我所知道的所有架构上，以上代码都可以正常运行。教编译器或运行时执行这种情况的分析非常困难和昂贵。不要忘记，在delete和使用指针之间可能有数百万行代码。将指针设置为null后立即进行delete可能很昂贵，因此这也不是一种通用解决方案。
这就是为什么存在UB的概念。您不希望在代码中出现UB。它可能有效，也可能无效。在这个实现上有效，在另一个实现上则会出错。
delete的问题 - 而是开发者的问题。 - sharptooth几年前我曾经问过自己同样的问题。当我试图为一个写入空指针的函数的行为提供适当的定义时，我立刻停止了考虑。
并非所有设备都有受保护内存的概念。因此，你不可能依靠系统通过段错误或类似方式来保护你。并非所有设备都有只读内存，因此你不能简单地说写入操作什么也不做。我能想到的唯一其他选择是要求应用程序在没有系统帮助的情况下引发异常[或中止等]。但在这种情况下，编译器必须在每个内存写入之前插入代码来检查空指针，除非它可以保证指针自上次列表内存写入以来没有更改。这显然是不可接受的。
因此，将行为定义为未定义是我能够得出的唯一合乎逻辑的决定，而不是说“符合C++标准的编译器只能在具有受保护内存的平台上实现。”
int溢出被视为未定义行为的最重要的好处之一是，使用int循环计数器索引数组仍然可以将其优化为指针增量或其他操作，而无需额外检查循环是否一定会在不包装的情况下终止。请参见 Is there some meaningful statistical data to justify keeping signed integer arithmetic overflow undefined? 和 http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html。 - Peter Cordes