相关疑难解决方法(0)

阅读和观看此演示文稿:http: //boost-spirit.com/home/2011/06/12/ast-construction-with-the-universal-tree/
我发现了这个陈述 - 基本上我们建议不要使用语义动作.

我必须承认,我已经感受到了类似的东西:具有语义行为的语法实际上看起来有点难看.而且,当我需要扩展/改变它们时,它完全采用语义动作进行了大量的"微观管理".在演示文稿中演示的具有属性语法的方法似乎更加优雅和有前途.

所以我想问:这是一个"官方"观点吗？我应该学习如何使用属性语法并更详细地避免语义动作吗？如果是这样 - 我想=要求一些基本的(甚至是微不足道的)例子,展示这样的方法 - LISP解释器太复杂了我不能咀嚼......

一般情况:我无法弄清楚为什么我的Spirit语法/语义动作没有编译.

有时,编译器会抱怨分配或类型不兼容,我不知道什么是错的.问题出现在两个主要方面:

• 预测规则/表达式的合成属性的类型
  • 因此,预测哪些类型的属性可以合法地定义为规则的公开属性(依赖于构建转换,融合适配器或Spirit自定义点)
• 匹配我的语义动作的参数类型,以便
  • 编译器将能够编译函数调用
  • 调用不会在进程中调用不必要的隐式转换

编译器错误不是完全易处理的,文档是错误的,或者我误解了它.

无论如何,有没有办法确切地找出Spirit传入我的语义行为的方式？

示例代码:

struct mybase             { int a,b; };
struct myderived : mybase { int c,d; };

BOOST_FUSION_ADAPT_STRUCT(mybase,    (int,a)(int,b));
BOOST_FUSION_ADAPT_STRUCT(myderived, (int,a)(int,b)(int,c)(int,d));

auto base_expr = int_ >> int_; // avoids assigning to struct attribute

rule<decltype(f), mybase()   , space_type> base_       = int_ >> int_;
rule<decltype(f), myderived(), space_type> derived_    = base_ >> int_ >> int_;

myderived data;
bool ok = phrase_parse(f,l,derived_,space,data);

此代码无法编译,存在大量难以理解的错误.

(松散地改编自精神总表上的帖子)