我正在使用clang ast matcher从源文件中提取一些信息。现在，我还想知道源文件正在使用的头和依赖头的列表。例如，源文件abc.c具有以下标题：
#include <def.h>
//#include <def_private.h>
在clang matcher中，我需要确保clang知道def.h，它位于同一目录中。 def.h包括以下标题：
#include <iostream.h>
#include <string.h>
#include <float.h>
#include <math.h>
/*#include <boost>
* #inclde <fstream>*/
我做了匹配来从abc.c中提取或识别信息。现在，我想提取所有标题或包含。这应该包括所有这些：
#include <def.h>
#include <iostream.h>
#include <string.h>
#include <float.h>
#include <math.h>
我做了一些在线研究，不幸的是所有这些都涉及正则表达式（Regular expression to extract header name from c file）或如何在visual studio中进行（Displaying the #include hierarchy for a C++ file in Visual Studio）。
我想知道是否有可能使用clang。另外，如果有任何其他方式以编程方式提取不仅仅使用正则表达式的标题，请告诉我。
答案 0 :(得分：0)
OP表示以任何其他方式以编程方式提取标头的方法不只是使用正则表达式。 ....没有叮当声是可以的。
我们都同意正则表达式根本无法做到这一点。您需要将源文本解析为树，并在树中显式显示#include指令。
我不是Clang专家。我怀疑其内部树反映了经过预处理的源，因此#include构造已消失。那么问题就是坚持对源文本进行预处理以对其进行解析。
我们的DMS Software Reengineering Toolkit及其C++17 capable parser可以在不扩展指令的情况下处理此类解析。它可以通过两种方式进行操作：a）在相对于源代码“预处理器”指令“结构良好”的情况下，可以将C ++前端配置为捕获解析树，并且这些指令也被解析为适当位置的树；这在实践中效果很好，但有时需要手动修补特别丑陋的条件或宏调用以使其“结构良好”，或者b）解析捕获以（几乎）任意方式放置的预处理器指令；这捕获了指令有时以自动复制少量代码为代价，实质上会导致情况a）所要求的良好重组。
无论哪种情况，#include指令现在都显式出现在AST中，其中包含的文件几乎被构建为代表包含文件的辅助树。寻找这种显式包含节点的树木漫步很容易找到此类树节点。 DMS的ASTInterface提供 ScanTree 来遍历节点，并在某些提供的谓词对节点为真时采取措施；检查#include节点很容易。值得注意的是，因为条件指令也被保留了，通过从#include onr向上沿树走就可以构造出实际包含include文件的条件。
当然，头文件本身也会被解析，从而生成一棵树。任何包含它的东西都已出现在其树体中。必须在所有这些树上运行ScanTree才能收集所有包含文件。
OP没有说出他想对#includes做什么。 DMS提供了许多解析之外的方法来帮助OP实现其目的，包括符号表构造，控制和数据流分析，树模式匹配，以源语言（C ++）语法表示的树到树转换以及最终的源代码（重新）从修改后的语法树生成。