c++ - 在 C++ 编译过程中，上下文敏感性在哪里得到解决？

Question

昨天我问了关于 C++ 上下文敏感性的问题，参见 here .在众多优秀答案中，here是被接受的，通过 dmckee .

但是，我仍然认为对此有话要说(也许是一些术语混淆？)。问题是:编译的哪一部分处理歧义？

为了澄清我的术语:CFG 是一种语法，它在规则的左侧只有一个非终结符(例如 A->zC)，CSG 是在左侧 (aAv->QT) 有一个终结符(加上一个非终结符)，其中大写字母是非终结符，小写字母是终结符。

在语法解析C++源码中有没有类似后者的表现形式？

谢谢，很抱歉推送这个问题。

Answer 1

没有我所知道的 C++ 前端(解析器、名称/类型解析器)( including the one we built ) 使用您定义的 CSG 语法规则实现上下文相关的解析器。几乎它们使用仍然有歧义的上下文无关语法显式或隐式操作。

他们中的许多人结合使用自上而下的解析和类型信息的交织集合来区分不明确的情况。

将解析和类型收集结合在一起使得以这种方式构建解析器变得非常困惑和困难，产生了民间定理“C++ 很难解析”。

像许多这样的“定理”一样，这不是真的，除非你也坚持用一只手绑在背后进行解析(例如，递归下降、LL(k)、LALR [例如，YACC])。如果使用可以处理歧义的解析技术，C++语法其实没有那么难。我们(和其他人，例如 Elsa C++ 解析器)为此使用 GLR 解析技术。 (我们更进一步，在 C++ 语法中捕获宏定义、使用和预处理器条件，因为我们有兴趣在处理器破坏代码之前转换代码；通常预处理器指令在独立的预处理器中完全分开处理)。

我认为 Elsa 仍然将歧义消除交织到解析过程中，但因为解析非常干净，所以更容易做到。我们的前端构建一个带有歧义节点的 AST，在构建树之后，我们使用属性语法评估器遍历树以收集名称和类型，并消除那些类型不一致的歧义分支。后者是一个非常漂亮的方案，并且完全解耦了解析和名称解析。

的困难实际上是进行名称解析。 C++ 有一个非常神秘的查询方案，它分布在标准的 600 页中，并且被各种方言以各种方式弯曲。将名称解析与解析分开使这种丑陋更易于管理，但民间定理应该是“C++ 很难进行名称解析”。