【问题标题】:Boost.Spirit adding #include feature into calculator exampleBoost.Spirit 在计算器示例中添加#include 功能
【发布时间】:2014-08-02 16:49:42
【问题描述】:

按照 Boost.Spirit 编译器示例,我正在将基于 Flex/Bison 的类似计算器的语法迁移到基于 Spirit 的语法。我想添加一个功能#include<another_input.inp>。我已经成功定义了 include_statement 语法。我是否应该遵循错误处理的方式:on_success(include_statement, annotation_function(...)),即对于 include_statement 的每个成功匹配,获​​取新的输入文件名并再次调用phrase_parse()?还是像 Flex/Bison 一样推送/弹出输入堆栈?

谢谢。

【问题讨论】:

  • 我不知道你的实际意思。 “我已经成功定义了 include_statement 语法”——也许你可以展示一下。一般来说,我的回答是:单独的解析和解释
  • 我的意思是说 AST 解析很好,而不需要进入包含的文件。您的意思是“包含”应该在解析而不是 AST 评估中?
  • 没有。我同意它应该在评估中。在这种情况下,我根本不明白你的问题。 on_success 与它有什么关系(在解析中)以及 Flex/Bison 的作用我不知道。

标签: c++ boost boost-spirit-qi


【解决方案1】:

从这里的少量信息中猜测,您的意思是询问是否可以重用相同的 grammar 实例,或者最好实例化一个新实例来解析包含,这取决于。

两者都可以。

当语法是无状态的(提示:它通常是如果你可以使用它const)没有区别。否则,最好实例化一个单独的实例。

然而,

  • 这点有点没有实际意义,因为您似乎已经决定在解析主文档后解析包含(如果我的评论正确的话)
  • 全局状态总是有危险的;即使grammar 对象是const,您也可能会修改外部状态(例如,使用语义操作中的phx::ref)因此,无论您是否使用单独的语法实例,这都是一个问题。

【讨论】:

  • 这里我举个例子:input1.txt: a = 3; b = a + 1;输入2.txt:包括(“输入1.txt”); c = a + b;这两个文件使用相同的语法,我只想要一个功能将一个输入拆分为多个文件并将它们包含在一个主文件中。我使用的方法是:首先将主文件解析为 AST 并循环遍历它以找到任何“包含”语句,然后再次解析子文件(无无限循环检测)并将这个新解析的 AST 插入主 AST。但是在“include”语句之后立即解析子文件更好吗(如递归)?但这有多容易?
  • 我看不出在解析主文件的过程中如何更好地解析子文件。 KISS 规则。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2021-12-12
  • 2017-05-13
  • 1970-01-01
相关资源
最近更新 更多