生产编译器是否使用解析器生成器？答案

【问题标题】：Do production compilers use parser generators?生产编译器是否使用解析器生成器？
【发布时间】：2011-06-17 16:39:15
【问题描述】：

我听说“真正的编译器编写者”使用自己的手工解析器而不是使用解析器生成器。我还听说解析器生成器不适合现实世界的语言。据推测，有许多特殊情况很难使用解析器生成器来实现。我对此表示怀疑：

所以我的问题是：使用解析器生成器编写生产编译器是否合理，或者编译器社区认为使用解析器生成器是一个糟糕的设计决策？

【问题讨论】：

真正的程序员使用面包板。
我以为他们用的是蝴蝶xkcd.com/378
GLR 解析器可以很好地处理 C++。我们的工具使用 GLR 来解析各种 C++ 方言和其他 30 种语言。（有关“我们的工具”，请参阅我的简历）。
为 C++ 编写所有解析器规则，甚至 C++0x 并使用解析器生成器并没有那么难，但是即使您使用最好的 C++ 解析器，您也永远无法获得手工解析器的性能发电机。而解析 C++ 的性能非常重要。
@Gene 为什么手工解析器会击败 C++ 解析器生成器？考虑到写一个手工解析器是很多代码，是不是手工解析器可能会慢很多？

【解决方案1】：

对于它的价值，我相信 GCC 使用了 4.0 之前的解析器生成器，然后切换到手写递归下降解析器，因为它更易于维护和扩展。

解析器生成器确实会为“真实”语言“删减”，但将语法转换为可行的东西的工作量呈指数级增长。

编辑：链接到 GCC 文档，详细说明更改的原因和收益与成本分析：http://gcc.gnu.org/wiki/New_C_Parser。

【讨论】：

【解决方案2】：

我在一家公司工作了几年，我们或多或少地编写编译器。我们不太关心性能。只是减少工作/维护量。我们使用生成的解析器 + 手写代码的组合来实现这一点。理想的平衡是使用解析器生成器自动化简单、重复的部分，然后在自定义函数中处理困难的部分。

【讨论】：

【解决方案3】：

有时会使用这两种方法的组合，例如使用解析器生成代码，然后“手动”修改该代码。

其他方式是一些扫描器（词法分析器）和解析器工具允许它们添加自定义代码，附加到语法规则，称为“语义操作”。这种情况的一个很好的例子是，解析器检测通用标识符，并且一些自定义代码将一些特定标识符转换为关键字。

编辑：添加“语义动作”

【讨论】：