Stephan Bergmann wrote:
Kay Ramme - Sun Germany - Hamburg wrote:
Hi guys,
Thorsten Behrens wrote:
Eike Rathke <[EMAIL PROTECTED]> writes:
A specialized parser could almost certainly be faster than the general
SAX parser passing strings back and forth. I wouldn't do it with
lex/yacc though, they're a nightmare to maintain, and in case wrong
code
was generated, which can happen, you're almost lost. I'd prefer
boost::spirit instead, but it might be even more work to implement the
parser. I've no idea though whether boost::spirit would be suitable to
parse an ODF tree.
hm. I'd profile a larger test case beforehand - spirit is a recursive
parser vs. yacc being table-driven. But OTOH, maybe contemporary
optimizers are able to compensate for that. And I'd definitely bump
our boost to 1.33, then - spirit (and lots of other stuff) has been
improved a lot.
At least in theory an unlimited (in the sense of programming language
constructs etc.) parser generator, as yacc, should be better than a
limited one, as boost::spirit. I know, that in practice the gcc C++
parser, which was AFAIK originally a bison generated parser, has been
replaced by a hand written one. Which seems to show that bison does
_not_ generate optimal code.
yacc/bison can only handle lalr(1) grammars, so if it is
difficult/impossible to press your grammar into that form (and for C++
it is at least difficult), you are better off using some other approach
than lalr(1). This does not necessarily have anything to do with the
You are right.
performance of the resulting parser, and this definitely has nothing to
do with whether a parser generator is implemented as a stand-alone tool
or as an embedded DSL.
If I understand correctly (not yet taken a look at the code Thorsten
pointed to, but promise to do so :-), an embedded parser gets generated
at runtime, while yacc/bison generate the parser at compile time.
-Stephan
Kay
Reaching the point where the parser becomes the main bottleneck, we
should try out independent implementations, using boost::spirit and
bison/yacc. Personally, I am a fan of domain oriented prog. languages
and therefor would favor bison. But certainly would be open for
everything fast&clean :-)
Kay
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
