C ++标准将well-formed programs定义为
根据语法规则构造的C ++程序，可诊断 语义规则和一定义规则
我想知道是否所有格式正确的程序都可以编译（如果不是这样，哪种类型的错误会导致格式良好的程序与可编译问题之间的区别）。例如，包含歧义错误的程序是否被认为格式正确？
iCMS 回答：在C ++标准中，格式正确意味着代码可以编译吗？ （但理论上是）
格式正确的程序可能具有不确定的行为。
它在注释中，因此在技术上没有权威，但是似乎打算终止编译（或标准所说的“翻译”）在可能的UB范围内：
[intro.defs]
未定义的行为
本文档不要求其行为的行为
[注意：当本文档省略行为的任何明确定义或程序使用错误的构造或错误的数据时，可能会出现未定义的行为。允许的不确定行为包括从完全忽略具有不可预测结果的情况到在翻译或程序执行过程中以环境特征的书面方式记录的行为（有无诊断消息）到终止翻译或执行（带有诊断消息）。
许多错误的程序构造不会引起未定义的行为。他们需要被诊断。
对常量表达式的求值永远不会表现出在本文档的[intro]至[cpp]中明确指定为undefined的行为（[expr.const]）。 —尾注 ]
还有一些实际的实现限制：
[允许]
由于计算机是有限的，因此C ++实现不可避免地会限制它们可以成功处理的程序的大小。
每个实现应在已知的地方记录这些限制。该文档可能会引用固定限制存在的地方，例如如何根据可用资源来计算可变限制，或者说固定限制不存在或未知。
此外，编译器可以而且确实存在错误。格式正确的简单表示标准编译器应对其进行编译（在上述限制内）。有问题的编译器不一定符合标准。
最后，标准文档本身是not perfect。如果对于规则的含义存在分歧，则程序可能在一种解释下格式正确，而在另一种解释下格式错误。
如果一个编译器与程序员或另一个编译器不同意，则它可能无法编译被认为是由另一方编写的格式正确的程序。
,我想知道是否所有格式正确的程序都可以编译
当然不是。
一个典型的例子是当您要求包含大型C ++函数的巨大 optimizations上的translation unit时。
（但理论上是）
当然，请参见n3337 C ++ 11标准或C++17标准。
在（旧的）GCC MELT项目中，这发生在我身上。我正在生成由GCC编译的C ++代码，基本上是在我的发明的Lispy DSL上使用转译器（或source to source compilation）技术来生成GCC plugins的C ++代码。另请参见this和that。
实际上，如果生成包含十万条语句的单个 C ++函数，则编译器将无法对其进行优化。
在GUI代码生成器（例如FLUID）或某些解析器生成器（例如ANTLR（当基础输入语法设计不当时），接口生成器（例如{ {3}}，或使用诸如SWIG或GPP之类的预处理器（就像GNU m4一样）。 C ++ template扩展还可能产生任意大的函数（例如，在链接时与{{1}结合使用多个C ++ GNU autoconf模板和container GCC编译器到ask }）
我做了基准测试，并在过去十年中进行了实验观察，发现编译 n 语句的C ++函数可能需要 O（n 2 ） optimize（和IIRC O（n log n） time）和g++ -flto -O2。请注意，良好的优化C ++编译器必须执行space，register allocation，loop unrolling，某些inline expansion（包括ABI）强制传递或返回 small g++ -O3-s（或小的struct-s实例）通过寄存器。所有这些优化都需要权衡取舍，并且遇到了Linux/x86-64壁垒：实践中，编译器优化至少是combinatorial explosion，并且可能是intractable problem。另请参阅相关的undecidable并阅读Rice's theorem。
您可以调整我的Dragon Book程序（生成或多或少的随机C代码编译为多个manydl.c，然后在Linux上plugin-对其进行编译）以生成C ++。然后，您将能够执行一些GCC编译器基准测试，因为该class程序能够生成数十万个包含或多或少的随机C函数的插件。请参阅Drepper的论文dlopen，并注意how to write shared libraries。
另请参见libgccjit（1934-oct.2019）中的示例blog of the late Jacques Pitrat生成其自己的C代码的五百万行，其设计在C program中进行了说明， this paper。