On Tue, Nov 20, 2018 at 11:47 AM Michael Powell <mwpowellhtx@gmail.com> wrote:
Hello,
I am trying to figure out why the uint_parser yields what looks like raw characters in one instance, yet in another instance yields the original given phrase. What do I mean by that?
I got it sorted out. Truly was parsing correctly; one too many escapes happening on my end.
I have a string-literal rule, subset of the Google protobuf v2 grammar, and the octal-escaped rule yields a raw character, but the "same" hex-escaped rule yields the given input string.
Both rules are of type qi::rule<It, char()>. And the str_lit rule is qi::rule<It, std::string()>, basically.
oct_esc %= '\\' >> uint_parser<unsigned char, 8, 3, 3>{}; hex_esc %= no_case["\\x"] >> uint_parser<unsigned char, 16, 2, 2>{}; char_val %= hex_esc | oct_esc | char_esc | ~char_("\0\n\\"); str_lit %= ("'" >> *(char_val - "'") >> "'") | ('"' >> *(char_val - '"') >> '"') ;
struct escapes_t : qi::symbols<char, char> { escapes_t() { this->add("\\a", '\a') ("\\b", '\b') ("\\f", '\f') ("\\n", '\n') ("\\r", '\r') ("\\t", '\t') ("\\v", '\v') ("\\\\", '\\') ("\\'", '\'') ("\\\"", '"') ; } } char_esc;
The only thing I can figure is that perhaps it has something to do with no-case having a secondary effect on the rule?
I do not care which way it lands, per se, in either raw or original string, although landing in the raw, that is, unescaped, has some advantages, I suppose.
However, it is a mystery to me how there are two different outcomes.
Any thoughts? Suggestions?
Thanks!
Michael Powell