当前位置:  开发笔记 > 编程语言 > 正文

boost.org的Spirit解析器 - 生成器框架有哪些缺点?

如何解决《boost.org的Spirit解析器-生成器框架有哪些缺点?》经验,为你挑选了4个好方法。

在几个问题中,我看到了来自boost.org的Spirit解析器 - 生成器框架的建议,但是在评论中,人们抱怨使用不开心的Spirit.请那些人站出来向我们其他人解释使用Spirit的缺点或缺点是什么?



1> Blaisorblade..:

这是一个非常酷的主意,我喜欢它; 真正学习如何使用C++模板特别有用.

但他们的文档建议使用精神用于中小型解析器.完整语言的解析器需要很长时间才能编译.我将列出三个原因.

无扫描解析.虽然它非常简单,但是当需要回溯时,它可能会降低解析器的速度.它是可选的 - 可以集成词法分析器,参见使用Spirit构建的C预处理器.大约300行(包括.h和.cpp文件)的语法使用GCC编译(未优化)到6M的文件.内联和最大优化可以达到约1,700万.

缓慢解析 - 没有静态检查语法,既不暗示需要过多的前瞻,也不验证基本错误,例如左递归的使用(这导致递归下降解析器LL语法中的无限递归).但是,左递归并不是一个非常难以追踪的错误,但过多的前瞻可能会导致指数解析时间.

大量使用模板 - 虽然这具有一定的优势,但这会影响编译时间和代码大小.此外,语法定义通常必须对所有其他用户可见,从而影响更多的编译时间.我已经能够通过使用正确的参数添加显式模板实例来将语法移动到.cpp文件,但这并不容易.

更新:我的回答仅限于我对Spirit经典的体验,而不是Spirit V2.我仍然希望Spirit基于模板,但现在我只是在猜测.



2> mmocny..:

在1.41版本中,一个新版本的Spirit正在发布,它的精神与经典之作:经典:

经过长时间的测试(使用Spirit 2.0超过2年),Spirit 2.1将最终在即将推出的Boost 1.41版本中发布.代码现在非常稳定,可以用于生产代码.我们正在努力为Boost 1.41及时完成文档.您可以在此查看文档的当前状态.目前,您可以在Boost SVN中继中找到代码和文档.如果您有一个涉及Spirit的新项目,我们强烈建议您现在从Spirit 2.1开始.请允许我在Spirit邮件列表中引用OvermindDL的帖子:

我可能听起来像机器人,我经常这么说,但是Spirit.Classic是古老的,你应该切换到Spirit2.1,它可以做你在上面做的所有事情,更容易,更少的代码,并执行快点.例如,Spirit2.1可以构建你的整个AST内联,没有奇怪的覆盖,不需要事后构建等等......所有这些都是一个不错的快速步骤.你真的需要更新.查看过去一天的其他帖子,获取Spirit2.1等文档的链接.Spirit2.1目前在Boost Trunk中,但将在Boost 1.41正式发布,但在其他情况下完成.



3> marcin..:

对我来说,最大的问题是,编译器或调试器看到的Spirit中的表达式相当长(我复制到Spirit Classic中一个表达式的一部分下面).这些表情让我害怕.当我处理使用Spirit的程序时,我害怕使用valgrind或在gdb中打印回溯.

boost::spirit::classic::parser_result, boost::spirit::classic::ref_actor >, boost::spirit::classic::clear_action> >, boost::spirit::classic::ref_actor >, boost::spirit::classic::clear_action> >, boost::spirit::classic::sequence, boost::spirit::classic::chlit >, boost::spirit::classic::positive >, boost::spirit::classic::chlit > > > >, boost::spirit::classic::ref_value_actor >, boost::spirit::classic::push_back_action> >, boost::spirit::classic::action, boost::spirit::classic::match_policy, boost::spirit::classic::action_policy> >, boost::spirit::classic::nil_t, boost::spirit::classic::nil_t>, boost::spirit::classic::ref_const_ref_actor >, std::string, boost::spirit::classic::push_back_action> > >, boost::spirit::classic::contiguous, boost::spirit::classic::action, boost::spirit::classic::ref_value_actor >, boost::spirit::classic::push_back_action> > > > >, boost::spirit::classic::kleene_star, boost::spirit::classic::alternative, boost::spirit::classic::chlit >, boost::spirit::classic::positive >, boost::spirit::classic::chlit > > > >, boost::spirit::classic::ref_value_actor >, boost::spirit::classic::push_back_action> >, boost::spirit::classic::action, boost::spirit::classic::match_policy, boost::spirit::classic::action_policy> >, boost::spirit::classic::nil_t, boost::spirit::classic::nil_t>, boost::spirit::classic::ref_const_ref_actor >, std::string, boost::spirit::classic::push_back_action> > >, boost::spirit::classic::contiguous, boost::spirit::classic::action, boost::spirit::classic::ref_value_actor >, boost::spirit::classic::push_back_action> > > > > > > > >, void ()(char const, char const*)>, boost::spirit::classic::scanner, boost::spirit::classic::match_policy, boost::spirit::classic::action_policy> > >::type boost::spirit::classic::action



4> user51568..:

这是我不喜欢的:

文件有限.有一个很大的网页,其中解释了"一切",但目前的解释缺乏细节.

AST生成不佳.AST很难解释,甚至在撞到墙上以了解AST修饰符如何工作之后,很难获得易于操作的AST(即很好地映射到问题域的AST)

它极大地增加了编译时间,即使对于"中等"大小的语法也是如此

语法太重了.生活中的事实是,在C/C++中,您必须复制代码(即在声明和定义之间).但是,似乎在boost :: spirit中,当你声明一个语法<>时,你必须重复一些东西3次:D(当你想要AST时,这就是我想要的:D)

除此之外,考虑到C++的局限性,我认为它们在解析器方面表现相当不错.但我认为他们应该更多地改进它.历史页面描述了当前"静态"精神面前的"动态"精神; 我想知道它有多快,语法有多好.

推荐阅读
和谐啄木鸟
这个屌丝很懒,什么也没留下!
DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有