格式良好的程序可能具有未定义的行为。

这是一个注释，因此在技术上不是权威的，但似乎它的意图是终止编译（或标准所称的“翻译”）是在可能的UB:

[intro.defs]

未定义的行为

本文档没有要求的行为[注:当本文档省略了行为的任何显式定义，或者当程序使用错误的构造或错误的数据时，可能会出现未定义的行为。 允许的未定义行为范围从完全忽略情况并产生不可预测的结果，到在翻译或程序执行期间以环境特征的记录方式（有或没有发布诊断消息）行为，到终止翻译或执行（有发布诊断消息）。 许多错误的程序构造不会产生未定义的行为； 他们需要被诊断。 常量表达式的求值从不显示本文档([expr.const])的[intro]到[cpp]中显式指定为未定义的行为。 -结尾注释]

还有实际的实施限制:

[暗示]

因为计算机是有限的，C++实现不可避免地受到它们能够成功处理的程序大小的限制。 在已知的情况下，每个实施都应记录这些限制。 本文档可能会引用存在固定限制的情况，说明如何根据可用资源计算可变限制，或者说明固定限制不存在或未知。

此外，编译器可能有，而且确实有bug。 格式良好只是指符合标准的编译器应该编译它（在上面提到的限制范围内）。 有错误的编译器不一定符合标准。

最后，标准文档本身并不完善。 如果对规则的含义存在分歧，那么程序在一种解释下可能是格式良好的，而在另一种解释下则可能是格式不良的。

如果一个编译器与程序员或另一个编译器的意见不一致，那么它可能无法编译另一方认为格式良好的程序。

我想知道是否所有格式良好的程序都能编译

一个典型的例子是当您要求对包含长C++函数的巨大翻译单元进行优化时。

这在（旧的）GCC熔体项目中发生在我身上。 我正在生成由GCC编译的C++代码，基本上是在我发明的Lispy DSL上使用transpiler（或源到源编译）技术。

在实践中，如果您生成一个包含十万条语句的C++函数，编译器在优化它时就会遇到麻烦。

在GUI代码生成器（例如FLUID）中，或者在一些解析器生成器（如ANTLR）中（当底层输入语法设计得很糟糕时），生成的大型C++函数是可能的。

我做过基准测试，在过去的十年中实验观察到，用g++-o3编译一个由n条语句组成的C++函数可能需要O(n²)时间（和IIRC O（n log n）空间

您可以将我的许多dl.C程序（生成编译为插件的C代码，然后dlopen-在Linux上运行它）改编为C++。

另请参阅本报告草稿（解释有关g++编译的更多信息）和RefPerSys项目（生成C++代码）。 阅读已故的Jacques Pitrat（1934-2019年10月）的博客，可以找到一个C程序生成50万行自己的C代码的例子，本文和那本书都对其设计进行了解释。

阅读《在拥挤和变化的世界中欣欣向荣:C++2006-2020