Re: [Boost-users] [Spirit] Qi lexeme only taking the first word

On Tue, Nov 6, 2018 at 5:40 PM Michael Powell wrote:

On Tue, Nov 6, 2018 at 5:01 PM Michael Powell wrote:

...

Hello,

I've got a couple of rules that are perplexing to me. First,

rule id %= lexeme[qi::alpha >> *char_("A-Za-z0-9_")];

In and of itself, id is working fine. Then I've got a "full id":

rule full_id %= id >> *(char_('.') >> id);

Where:

struct full_id_t { std::string val; };

full_id_t::val is quite intentional for reasons elsewhere in the grammar.

The perplexity comes in, it seems lexeme is only shaving off the first word as the val.

For instance, parsing "two.oranges.red.test", I receive back "two" in the AST.

Perhaps I should defer specifying the lexeme part of id until later?

I elaborated a little on the "simple" full id sub-grammar, but I cannot repro using the GCC compiler. I'm wondering if this has anything to do with the VS2017 fpos issue?

http://coliru.stacked-crooked.com/a/adeb42ce2f19b0fd

Or there may be insufficient context in the web compiler to adequately demo.

I got a repro: http://coliru.stacked-crooked.com/a/069a44296240be7e Although the reasons as to why I do not know. It is a difference in attribute synthesis. When full_id synthesizes a std::string(), the conversion to full_id_t() "just works" magically. I'm guessing by happy accident based on the std::string val being the only member (adaptation, etc). But when I change the synthesis to be its "true" type, that is, AST::full_id_t(), suddenly I see the same behavior. Really and truly, I do not know why. Everything else being equal why would one approach be any different than the other? Anyone with some Spirit, Fusion, AST, insights? Thanks! For now, I'll run with it as has been exposed here, but it's a bit troubling to me not knowing the difference.

...

Thoughts? Suggestions?

Thank you!

Best regards,

Michael Powell