如何实现解析树？
我开始编写DBM作为一个学习项目，现在我正在为DBMS中使用的语言实施Lexer/Parser。
我是从各种不同的资源中自己学习的，并设法为语言编写了Lexer和语法，但是我坚持编写代码来生成解析树。
每次我的Google解析器时，我只会获得有关如何手工构造解析树的结果（显示您的图表和Whatt），但没有关于如何实现它的实际代码。
这是我的项目
https://github.com/abdulaziz-com/abdulaziz-sama/accounting_db 语法写在解析器中的评论中。
我想解决的问题是为每个制作编写一个结构，类似：
struct production {
non-terminal_1* x;
non_terminal_2* y;
terminal z;
};
并将其用作树中的节点，但是我不确定这是否是正确的方法还是有更好的解决方案？
I started writing a DBMS as a learning project, and now I'm implementing the lexer/parser for the language used in the DBMS.
I'm learning on my own from various different resources, and managed to write the lexer and the grammar for the language, but I'm stuck at writing the code to generate the parse tree.
Every time I google parsers I only get results on how to construct the parse tree by hand (showing you diagrams and whatnot) but no actual code on how to implement it.
Here's the repo for my project
https://github.com/abdulaziz-sama/accounting_db
The grammar is written in the comments in parser.h
The way I'm thinking of solving this problem is by writing a struct for each production, something like:
struct production {
non-terminal_1* x;
non_terminal_2* y;
terminal z;
};
and use them as node in the a tree, but I'm not sure if this is the right way or if there are better solutions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
假设您使用的是普通C，而不是C ++。
有很多方法。一种简单的可能性是定义类似于ML风格语言的内存布局的通用标记的N键盘结构：
依此类推，您已经有了这个想法。您也必须定义简单数据的盒装版本（整数，浮点，字符串等）。实施宏来访问元组元素。理想情况下，编码标签本身中n核的元素数量。
这样，您就没有针对解析树的刚性数据类型，因此更改它会更容易。您还可以定义一个动态的DSL，用于与这些数据结构匹配的模式，这将使您的代码少得多。
Assuming you're using plain C and not C++.
There are many ways. One simple possibility is to define generic tagged N-tuple structures similar to the memory layout of the ML-style languages:
And so on, you've got the idea. You'll have to define boxed versions of simple data (integers, floats, strings, etc.) too. Implement macros for accessing tuple elements. Ideally, encode the number of elements of N-tuple in the tag itself.
This way you don't have a rigid data type for your parse tree, so making changes to it is easier. You can also define a dynamic-ish DSL for pattern matching these data structures, which will make your code much less convoluted.