[qi] order of aleternatives

[CARL BARRON-3]

I thougt    x =  a | b | c | d ;  would do

if a matches  then  match found
else if b matches then match found
else if c matches then match found
else if d matches then match found
else match not found

How ever integere in attached code appears to test zero (last  
alternative) first, is this a bug
or a feature??   All integer is supposed to do is determine base and  
convert text to a 32 bit unsigned integer,   This is a simple qi  
parser of ipv4_addresses no lex.

 

Macintosh:debug carlbarron$ ls
a2
Macintosh:debug carlbarron$ ./a2
<addr>
  <try>0x1.01.1.0</try>
  <dotted>
    <try>0x1.01.1.0</try>
    <integer>
      <try>0x1.01.1.0</try>
      <zero>
        <try>0x1.01.1.0</try>
        <success>x1.01.1.0</success>
        <attributes>(0)</attributes>
      </zero>
      <success>x1.01.1.0</success>
      <attributes>(0)</attributes>
    </integer>
    <fail/>
  </dotted>
  <integer>
    <try>x1.01.1.0</try>
    <zero>
      <try>x1.01.1.0</try>
      <fail/>
    </zero>
    <fail/>
  </integer>
  <fail/>
</addr>
parse fails
Macintosh:debug carlbarron$





------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Spirit-general mailing list
Spirit-general@...
https://lists.sourceforge.net/lists/listinfo/spirit-general

[Joel de Guzman-2]

Carl Barron wrote:

> I thougt    x =  a | b | c | d ;  would do
>
> if a matches  then  match found
> else if b matches then match found
> else if c matches then match found
> else if d matches then match found
> else match not found
>
> How ever integere in attached code appears to test zero (last
> alternative) first, is this a bug
> or a feature??   All integer is supposed to do is determine base and
> convert text to a 32 bit unsigned integer,   This is a simple qi parser
> of ipv4_addresses no lex.

Hmmm.. Looks like a bug indeed :(.
Can you simplify the code to a minimum test case?

Regards,
--
Joel de Guzman
http://www.boostpro.com
http://spirit.sf.net


------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Spirit-general mailing list
Spirit-general@...
https://lists.sourceforge.net/lists/listinfo/spirit-general

[Hartmut Kaiser]

> Carl Barron wrote:
> > I thougt    x =  a | b | c | d ;  would do
> >
> > if a matches  then  match found
> > else if b matches then match found
> > else if c matches then match found
> > else if d matches then match found
> > else match not found
> >
> > How ever integere in attached code appears to test zero (last
> > alternative) first, is this a bug
> > or a feature??   All integer is supposed to do is determine base and
> > convert text to a 32 bit unsigned integer,   This is a simple qi
> parser
> > of ipv4_addresses no lex.
>
> Hmmm.. Looks like a bug indeed :(.
> Can you simplify the code to a minimum test case?

It's not a bug. These are wrong:

    qi::uint_parser<uint32_t,16,-1,-1>  hex_int;
    qi::uint_parser<uint32_t,8,-1,-1>  octal_int;

The third template arguments are treated as unsigned ints, which requests
matching of at least (uint)(-1) digits, which is clearly not the desired
functionality. Change that to:

    qi::uint_parser<uint32_t,16,1,-1>  hex_int;
    qi::uint_parser<uint32_t,8,1,-1>  octal_int;

or just

    qi::uint_parser<uint32_t,16>  hex_int;
    qi::uint_parser<uint32_t,8>  octal_int;

or even simpler, just use the predefined parsers 'hex' and 'oct' instead.
Then everything works as expected.

Regards Hartmut

>
> Regards,
> --
> Joel de Guzman
> http://www.boostpro.com
> http://spirit.sf.net
>
>
> -----------------------------------------------------------------------
> -------
> Enter the BlackBerry Developer Challenge
> This is your chance to win up to $100,000 in prizes! For a limited
> time,
> vendors submitting new applications to BlackBerry App World(TM) will
> have
> the opportunity to enter the BlackBerry Developer Challenge. See full
> prize
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> Spirit-general mailing list
> Spirit-general@...
> https://lists.sourceforge.net/lists/listinfo/spirit-general

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Spirit-general mailing list
Spirit-general@...
https://lists.sourceforge.net/lists/listinfo/spirit-general

[CARL BARRON-3]

On Jul 8, 2009, at 9:17 PM, Hartmut Kaiser wrote:

>> Carl Barron wrote:
>>> I thougt    x =  a | b | c | d ;  would do
>>>
>>> if a matches  then  match found
>>> else if b matches then match found
>>> else if c matches then match found
>>> else if d matches then match found
>>> else match not found
>>>
>>> How ever integere in attached code appears to test zero (last
>>> alternative) first, is this a bug
>>> or a feature??   All integer is supposed to do is determine base and
>>> convert text to a 32 bit unsigned integer,   This is a simple qi
>> parser
>>> of ipv4_addresses no lex.
>>
>> Hmmm.. Looks like a bug indeed :(.
>> Can you simplify the code to a minimum test case?
>
> It's not a bug. These are wrong:
>
>    qi::uint_parser<uint32_t,16,-1,-1>  hex_int;
>    qi::uint_parser<uint32_t,8,-1,-1>  octal_int;
>
> The third template arguments are treated as unsigned ints, which  
> requests
> matching of at least (uint)(-1) digits, which is clearly not the  
> desired
> functionality. Change that to:
>
>    qi::uint_parser<uint32_t,16,1,-1>  hex_int;
>    qi::uint_parser<uint32_t,8,1,-1>  octal_int;
>
> or just
>
>    qi::uint_parser<uint32_t,16>  hex_int;
>    qi::uint_parser<uint32_t,8>  octal_int;
>
> or even simpler, just use the predefined parsers 'hex' and 'oct'  
> instead.
> Then everything works as expected.

   It is a bug but not in spirit:)   BTW I fixed the lexer version so  
it works.  The lexer version illustrates various phoenix actions, but  
is nowhere no as simple as this parser.  This may be why there is  
little 'lex action' here...



------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Spirit-general mailing list
Spirit-general@...
https://lists.sourceforge.net/lists/listinfo/spirit-general