Boost logo

Boost :

From: Zach Laine (whatwasthataddress_at_[hidden])
Date: 2008-07-25 14:41:49


I've been eagerly anticipating the new version of Spirit ever since
BoostCon 07. I've been using the code from the release branch to play
around with it a bit, and I have a few concerns about its usability.

I specifically have been using it to replace some rather ugly parsing
code in an existing library. This code parses tagged text for use in
a GUI, e.g. "Some text, <i>partially italicized</i>." This is very
similar to the mini_xml example in the docs, so I used that as a
starting point. There are some key differences between the simple_xml
format and my needs, and as soon as I started deviating from the
example too far I started having troubles. The differences are:

1) A tag can have parameters, and they don't look exactly like xml
attributes, e.g. "<color 255 255 255 127>translucent white
text</color>".
2) The "<pre>" tag is special. It turns off recognition of all future
tags until the next "</pre>" end-tag is seen.
3) Stray "<" characters in the non-tag parts of the input are fine.

1) and 2) were fairly straightforward to implement as changes to
simple_xml, but 3) has so far eluded me. 3) requires that all ">"
sequence operators be changed to ">>" in the tagged-text parsing, so
that more extensive backtracking can be done to ensure a stray "<" is
not actually part of a tag.

I'll summarize briefly the problems I had in terms of surprises,
counterintuitive interfaces, and compilation failures that left me
nonplussed. I've attached the full source (only one file, called
"test.cpp"), and there are numerous comments in that code that are
more direct and explicit. All my efforts were done with various
recent revisions, most recently HEAD at the time of this writing --
47802. Everything was done on a Linux box with GCC 4.1.2.

- Auto-assignment seems to work fine for simple expressions, and fail
for only slightly more complicated ones that the user would not
expect. See Line 61.
- Alternative expressions do not seem to work in a greedy fashion in
all cases. See Line 70.
- The rules for whether a character parser has an attribute or not are
sure to seem arbitrary to everyday users. See Line 83.
- In at least one case, a rule whose attribute was explicitly declared
to be a type I defined (TaggedText) stubbornly insisted its attribute
was std::string. See line 117.
- Changing the ">" sequence operators (which seem to work nicely with
"%=") to ">>" sequence operators makes the use of "%=" produce
compilation errors. This forces one to resort to using semantic
actions like in Spirit 1. See Line 124.

On a different note, two of the Qi examples do not compile. They are
actions and calc3_lexer. I did not try to compile the others
(Karma, etc.). All tests (for everything -- not just Qi) pass.

Zach Laine




Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk