1

I've got an embarrassingly simple problem that I can't seem to wrap my head around. I'm reading the boost documentation on how to parse into structs. The sample code provided for that chapter is straightforward - or so I thought. I would like to make a super simple change.

I want to split the start-rule:

start %=
    lit("employee")
    >> '{'
    >>  int_ >> ','
    >>  quoted_string >> ','
    >>  quoted_string >> ','
    >>  double_
    >>  '}'
    ;

...into two (or later more) rules, like this:

params %=
    >>  int_ >> ','
    >>  quoted_string >> ','
    >>  quoted_string >> ','
    >>  double_;

start %=
    lit("employee")
    >> '{'
    >> params
    >> '}'
    ;

No matter what I've tried I couldn't get it to parse values correctly into the employee struct. Even when I got a running program that recognized the input, the attributes didn't get written to the struct. It seems parsing only works correctly if everything is specified in the "top-level" rule. Surely, I'm mistaken?! I'll definitely need a more structured approach for the parser I actually need to implement.

Also I'm unclear what the correct type of the params rule should be. I'm thinking qi::rule<Iterator, fusion::vector<int, std::string, std::string, double>, ascii::space_type>, but my compiler didn't seem to like that very much...

I should mention that I'm working with Boost v1.46.1

djf
  • 6,592
  • 6
  • 44
  • 62

1 Answers1

2

In this situation, you could really just make params expose an employee attribute directly:

Live On Coliru

qi::rule<Iterator, employee(), ascii::space_type> params;
sehe
  • 374,641
  • 47
  • 450
  • 633
  • Oh Jeez... Thank you, sehe! I've been expecting your answer :) Do you happen to know why a `fusion::vector` isn't implicitly convertible to the target struct in such a situation? Can you point me to the relevant chapter(s) in the docs? – djf Oct 20 '14 at 10:33
  • I think the attribute compatibility rules govern how the _synthesized_ attributes are transformed to _exposed attributes_. In your situation, however, it would already be the _exposed_ attribute type from the rule definition, hence not "prone" to such compatibilty rules (?). All I can say, really, is that it is a-typical to "camouflage a `rule<>`" by returning as-if synthesized attribute types. I don't think there's any direct documentation that we can point to (in fact, this is by design: the attribute compat. magic should be "intuitive" and an implementation detail, ideally) – sehe Oct 20 '14 at 11:26