c++ - C++ 代码的符号表是否包含函数名和类名？

Question

我一直在搜索有关 C++ 代码的符号表是否包含函数名称和类名称的各种帖子。我可以在帖子上找到的东西是它取决于编译器的类型，

如果它一次性编译代码，则不需要在符号表中存储类名和子例程名

但是如果它是一个多 channel 编译器，它可以添加有关它遇到的类及其子例程的信息，以便它可以进行参数类型检查并发出有意义的错误消息。

我不明白它是否真的依赖于编译器？我假设编译器(对于 C++ 代码)会将函数名和类名放在表中，无论是单程还是多程编译器。它如何依赖于通行证？我没有如此丰富/深入的知识。
此外，任何人都可以显示一个简单的 C++ 类的示例符号表，它会是什么样子(带有类名的函数名)？

Answer 1

大多数编译器教科书会告诉您有关符号表的信息，并且通常会向您展示有关中等复杂性语言(例如 Pascal)的详细信息。您不会在教科书中找到有关 C++ 符号表的信息；这太神秘了。

我们为 DMS 软件再造工具包提供完整的 C++14 前端。它解析 C++，构建 detailed ASTs ，并执行名称和类型解析，其中包括构建精确的符号表。

以下是我们关于如何使用 DMS 的教程的幻灯片，重点介绍 C++ 符号表结构。

OP 专门询问了类会发生什么。下图显示了左上角的微型 C++ 程序。图表的其余部分显示了框，它们代表我们所谓的“符号空间”(或“范围”)，它们本质上是将符号名称(每个框列出其拥有的符号)映射到 DMS 知道的关于该符号的信息的哈希表(定义的源文件位置，引用定义的 AST 节点列表，以及表示类型的复杂 union ，并且可能又指向其他类型)。箭头显示符号空间是如何连接的；从空间 A 到空间 B 的箭头表示“范围 A 包含在范围 B 内”。通常，符号空间查找过程，在作用域 A 中搜索符号 x，如果在 A 中找不到 x，将继续在作用域 B 中搜索。您会注意到箭头用整数编号；这告诉搜索机制首先查看编号最少的父范围，然后尝试使用具有较大数字的箭头搜索范围。这就是作用域的排序方式(注意 C 类继承自 A 和 B；对 C 类中的任何字段(例如“b”)的任何查找都将被迫首先在 A 的作用域中查找，然后在 B 的作用域中查找。这样就实现了C++的查找规则。

请注意，类名记录在(唯一的)全局命名空间中，因为它们是在顶层声明的。如果它们是在某个显式命名空间中定义的，那么命名空间将有自己的相应符号空间来记录声明的类，而命名空间本身将被记录在全局符号空间中。



OP 没有询问函数体的符号表是什么样的，但我碰巧在下面也有一张说明性幻灯片。
符号空间的工作方式相同。此幻灯片中显示的是符号空间与其代表的作用域区域之间的联系。该链接实际上是由与符号空间关联的指针实现的，指向相应的 AST(命名空间定义可以分散在多个地方)。

请注意，在这种情况下，函数名称记录在全局命名空间中，因为它是在顶层声明的。如果它是在类的范围内定义的，则函数名称将被记录在类主体的符号空间中(在上图中)。



作为一般规则，符号表如何组织的细节完全取决于编译器和设计者所做的选择。在我们的例子中，我们设计了一个非常通用的符号表管理包，因为我们计划(并且已经)使用同一个包以统一的方式处理多种语言(C、C++、Java、COBOL、几种遗留语言)。
但是，符号空间和继承的抽象结构必须在 C++ 编译器中以本质上等效的方式实现；毕竟，他们必须对相同的信息进行建模。我希望 GCC 和 Clang 编译器中有类似的结构(好吧，整数编号的继承弧，也许不是:)

实际上，编译器有多少“通过”并不重要。它几乎必须构建这些结构来记住它对符号的了解，在一次传递中和跨传递。

虽然 building a C++ parser is very hard by itself ，构建这样的符号表要困难得多。这种努力使构建 C++ 解析器的努力相形见绌。我们的 C++ 名称解析器是由 DMS 编译和执行的大约 250K SLOC 的属性语法代码。获得细节权利是一件非常头疼的事情； C++ 引用手册是巨大的、令人困惑的，事实散布在整个文档的各个地方，并且在很多地方都是矛盾的(我们尝试向委员会发送有关此问题的投诉)和/或编译器之间的不一致(我们有 GCC 的版本)和 Visual Studio 201x)。

2017 年 3 月更新:现在有 C++2014 的符号表。
2018 年 6 月更新:现在有 C++2017 的符号表。