[Spirit] uint_parser inconsistent results

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[Spirit] uint_parser inconsistent results

Boost - Users mailing list
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 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
_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: [Spirit] uint_parser inconsistent results

Boost - Users mailing list
On Tue, Nov 20, 2018 at 11:47 AM Michael Powell <[hidden email]> 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
_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users