Re: [Boost-users] Boost.Spirit's Greedy Fundamental Type Parsers

Subject: Re: [Boost-users] Boost.Spirit's Greedy Fundamental Type Parsers
From: Lee Clagett (forum_at_[hidden])
Date: 2016-04-01 09:41:31

On Fri, 1 Apr 2016 09:07:30 +0200
Daniel Hofmann <daniel_at_[hidden]> wrote:
> On 04/01/2016 12:19 AM, Lee Clagett wrote:
> > On Thu, 31 Mar 2016 23:02:05 +0200
> > Daniel Hofmann <daniel_at_[hidden]> wrote:
> >   
> >> Suppose I want to parse a list of ";"-separated floating point
> >> pairs with "," being the pair separator as in "1,2;3,4". Following
> >> this list comes a string literal representing a file extension,
> >> such as ".txt".
[...]
> > I am not sure why you want to use a `double` in this situation, but 
> > 
> >    std::vector<unsigned> out;
> >    parse(first, last, (+(uint_ >> '.') >> "txt"), out);
> > 
> > or
> > 
> >    unsigned one = 0;
> >    boost::optional<unsigned> two;
> >    parse(
> >        first, last,
> >        (uint_ >> '.' >> -(uint_ >> '.') >> "txt"),
> >        one, two);
> > 
> > will prevent inputs that contain '-' or the various inputs that the
> > real parser [1] accepts. uint_ [2] can also be specialized to have a
> > min,max number of digits which might be useful to your situation.  
> 
> I'm parsing into a std::vector<double> since I want both
> 
> 1,2;3,4.txt
> 
> as well as
> 
> 1.1,2.2;3.3,4.4.txt
> 
> to succeed. With a uint_ based parser as you suggest, I get a vector
> of {1,1,..} for the second example, which does not represent the
> input or lets me reconstruct it.

You could use the optional parser to store this information:

    +(uint_ >> '.' >> -(uint_ >> '.')) >> "txt"

with attribute `vector<pair<unsigned, optional<unsigned>>>`.

> Looking at strict_real_policies<double> I was under the impression
> that the default real policy should work for both inputs above, being
> able to parse both inputs into a vector of {1.0, 2.0, 3.0, 4.0} and
> {1.1, 2.2, 3.3, 4.4} respectively.

The `double_` parser will allow inputs like "+1.1.txt" or "1e1.txt". So
hopefully these numbers are actual double values and not a versioning
scheme. The `ureal_policies` trait can restrict valid inputs with some
additional work. Overriding the behavior of `parse_exp`, `parse_exp_n`,
`parse_nan`, and `parse_inf` to reject everything AND providing a
static field `allow_leading_dot = false` might be enough. There is a
grammar [0] on the real parsers page describing all the inputs allowed.

Lee

[0]http://www.boost.org/doc/libs/1_60_0/libs/spirit/doc/html/spirit/qi/reference/numeric/real.html#spirit.qi.reference.numeric.real._code__phrase_role__identifier__realpolicies__phrase___code_