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.
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]
