This is the first of a two part article describing the use of the boost::spirit parser framework. Spirit is the best fully object oriented parser that I have seen, allowing a user to rapidly created fully functional parsers using highly object oriented code. This first article is intended to introduce a programmer to writing enough code to successfully parse some simple input. I will not deal with any semantic actions. The next article will actually plumb in some semantic actions and create a fully working modular arithmetic calculator.
[ posted via RSDN@Home 1.1.2 stable, accompanied by Metallica — Shoot Me Again ]
И что в нем хорошего.
Примитивный алгоритм парсинга LL&backtracking
и ужасный интерфейс — то ли () надо использовать то ли [] например — не поймешь
что перегужено
Огромный размер exe + пляски с бубнами для его уменьшение (вроде typeof)
У той области где он себя позиционирует лидируют регулярные выражения — хоть и
не обрабатывают CFG
ИМХО не было бы его в boost знать бы его никто не знал
PS
The Hapy library would not exist if Spirit would generate correct parsers by default, had data-push parsing interface, could recognize valid message prefixes, and would not take unreasonable amount of compilation time and/or bleeding-edge C++ compilers. While the last flaw is likely to disappear according to Moore's law, key Spirit design choices would keep it inappropriate for parsing communication protocol messages, one of the primary use cases for the Hapy library.
Re[2]: [ANN] An Introduction to the Boost Spirit Parser fram
Здравствуйте, SchweinDeBurg, Вы писали:
SDB>Здравствуйте, little_alex, Вы писали:
_>>И что в нем хорошего.
SDB>Сорьки за беспокойство в таком случае — я просто стараюсь постить здесь ссылки на статьи, которые мне кажутся интересными для форумчан.
Да не вам это
а скорее создателем spirit
хотя сам довольно хорошо в нем разобрался (по крайней мере до уровня это статьи)
Re[3]: [ANN] An Introduction to the Boost Spirit Parser fram
Здравствуйте, SchweinDeBurg, Вы писали:
SDB>Здравствуйте, little_alex, Вы писали:
_>>И что в нем хорошего.
SDB>Сорьки за беспокойство в таком случае — я просто стараюсь постить здесь ссылки на статьи, которые мне кажутся интересными для форумчан.
И правильно делаешь, что постишь, респект
А спирит вещь хорошая и далеко не всегда целесообразно и удобно заменять его regexpами
... << RSDN@Home 1.1.3 stable >>
Re[4]: [ANN] An Introduction to the Boost Spirit Parser fram
Интересующимся парсингом возможно будет таже интересно:
[ANN] xpressive v0.9, advanced C++ regular expressions
<<Description>>
xpressive is an advanced, object-oriented regular expression template
library for C++. Regular expressions can be written as strings which are
parsed at run-time, or as expression templates which are parsed at
compile-time. Regular expressions can refer to each other and to
themselves recursively, allowing you to build arbitrarily complicated
grammars out of them.
xpressive is a Boost.Regex work-alike which roughly follows the regex
standardization proposal, with minor deviations.
<<Example>>
In xpressive, the following two regular expressions are equivalent:
<<CVS>>
xpressive lives in the boost-sandbox project on sourceforge.net. It is
accessible via anonymous CVS.
<<Motivation>>
If you need to manipulate text in C++, you have typically had two
disjoint options: a regular expression engine or a parser generator.
Regular expression engines (like Boost.Regex) are powerful and flexible;
patterns are represented as strings which can be specified at runtime.
However, that means that syntax errors are likewise not detected until
runtime. Also, regular expressions are ill-suited to advanced text
processing tasks such as matching balanced, nested tags. Those tasks
have traditionally been handled by parser generators (like the Spirit
Parser Framework). These beasts are more powerful but less flexible.
They generally don't allow you to arbitrarily modify your grammar rules
on the fly. In addition, they don't have the exhaustive backtracking
semantics of regular expressions, which can make it more challenging to
author some types of patterns.
xpressive brings these two approaches seamlessly together and occupies a
unique niche in the world of C++ text processing. With xpressive, you
can choose to use it much as you would use Boost.Regex, representing
regular expressions as strings. Or you can use it as you would use
Spirit, writing your regexes as C++ expressions, enjoying all the
benefits of an embedded language dedicated to text manipulation. What's
more, you can mix the two to get the benefits of both, writing regular
expression grammars in which some of the regular expressions are
statically bound -- hard-coded and syntax-checked by the compiler -- and
others are dynamically bound and specified at runtime. These regular
expressions can refer to each other recursively, matching patterns in
strings that ordinary regular expressions cannot.
<<Contact>>
Please send any questions to:
eric@boost-consulting.com
> In fact, you can use regular expressions with Spirit and specify them at
> runtime as well.
>
> I use Spirit and happy with it. So, could you please contrast xpressive
> with Spirit?
Certainly. There is one thing xpressive can do that Spirit cannot:
exhaustive backtracking. Consider the following Spirit rule:
rule<> r = *ch_p('a') >> 'a';
It will never match because the Kleene star greedily gobbles up all the 'a's
and doesn't give any back when the rest of the rule fails to match.
That's not how xpressive works. If later parts of your pattern fail to
match, early parts are given a chance to try something different. That's
called exhaustive backtracking.
It's interesting you mention that you can embed regexes in Spirit rules,
because it highlights the differences between Spirit's approach and
xpressive's. Imagine that your embedded regex matches, but that the rest of
the rule fails. With Spirit, the embedded doesn't get a chance to backtrack
and try something different. With xpressive, embedded regexes *do* get a
chance to backtrack. They participate fully in the match.
The other difference between xpressive and Spirit is speed. By Joel de
Guzman's own measurements, xpressive is about 3.5 times faster than Spirit
in its present incarnation. (Spirit is currently undergoing a redesign to
address the performance problems. I'm helping with the redesign, when I
can.)
I should also point out that there are plenty of things Spirit does that
xpressive doesn't. Semantic actions leap to mind. xpressive has them, but
they're half-baked at this point. Spirit is an amazing tool, and far more
mature than xpressive is at this point. Joel and I are working closely --
look for xpressive and Spirit to converge over time, but for now the
differences remain.
Здравствуйте, little_alex, Вы писали:
_>Здравствуйте, SchweinDeBurg, Вы писали:
SDB>>An Introduction to the Boost Spirit Parser framework
_>И что в нем хорошего. _>Примитивный алгоритм парсинга LL&backtracking
Even if LL(inf) with full backtracking (as implemented in Spirit) is a 'primitive' type of parsing, nowadays it is used by several large C++ compilers to parse the C++ syntax.
_>и ужасный интерфейс — то ли () надо использовать то ли [] например — не поймешь _>что перегужено
The interface Spirit provides is quite easy to use, as only you have some interest in understanding what's going on and why something is implemented the way it is.
_>Огромный размер exe + пляски с бубнами для его уменьшение (вроде typeof)
No typeof at all. he large exe sizes are not a problem of Spirit, but an artifact of gcc|s inabilitz to handle complex templated code in an efficient manner. Moreover most of this siye goes awaz if zou strip the debug information. BTW, VC generates lean code from Spirit, no problems here.
_>У той области где он себя позиционирует лидируют регулярные выражения — хоть и _>не обрабатывают CFG
This is plainly wrong. Spirit is a parser framework, not a regular expression framework. And as such it is able to handle grammars not implementable using regular expressions (for instance parsing hierarchical data structures).
_>PS _>The Hapy library would not exist if Spirit would generate correct parsers by default.
The fact that this is a quote from the Hapy web site doesn't make it more correct. In fact, Spirit does generate correct parsers. Just look at the many applications Spirit has been used in.
