Boost logo

Boost Users :

From: Simon Buchan (simon_at_[hidden])
Date: 2005-10-13 22:17:20


Aaron Griffin wrote:
> Hi all,
>
> This is a contrived example, but the solution should be the same.
>
> Assuming I have two rules, like so:
> section = identifier >> ch_p('{') >> *setting >> ch_p('}');
> setting = identifier >> ch_p('=') >> value;
> // identifier and value are simple, but left off for brevity
>
> This should parse something like:
> somesettings
> {
> a = 12
> b = "hello whirled"
> }
>
> Now, what I am looking to do is, if the parser fails parsing a value
> inside a "section", the parsing itself does not fail, but that section
> itself does. So if I also had:
> moresettings
> {
> this_is_valid = 12345
> bigfaterror = 12"hi there"4.3"fewewfewfw"
> }
> Then the "somesettings" section would exist in the final AST, but
> "moresettings" would not. The error handling docs are a bit unclear
> to me, bit if I were to make a generic functor_parser which kept an
> error flag, how would I conditionally remove the section based on that
> value, seeing as it will already be mid-parse (I don't think something
> like if_p will work).
>
Just have a no_node parser after the failable bit:

section = identifier >> ch_p('{')
>> (*setting)
                           | no_node_d[!ch_p('}')]
>> ch_p('}');

(usual not-checked disclaimer)
note that if you are careful, you could have the parser simply ignore
the incorrect setting, or you could have an 'error node', or pretty much
anything you can think of.

This is if you want the error simply ignored: you may have to be a bit
tricker otherwise.

> Thanks in advance for any advice.
>
> On a side note, if I have a rule similar to (keyword >> identifier),
> the skip_parser will translate "somekeyword a" into "somekeyworda" and
> will parse it fine. However, what is to stop someone from removing
> the whitespace in the original code. With a quick glance, it appears
> the example c grammar from the spirit site will parse "voidfoo()" just
> fine due to this. Is there anyway I can tell the skip grammar to
> force a seperation?

Most parsers where this matters that I've seen don't actually define a
skip parser, they explicitly *space_p.
Alternitively, parse a token stream, not a char stream. I leave this as
an exersize for the reader ;-).


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net