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
Hi Joerg,
Joerg Budischewski wrote:
Hi,
sorry to warm this topic up again ...
While disagreeing to have such a bootstrap() function in cppuhelper
(this function simply can't work in SDK without office, how should
cppuhelper know, that it is running in an office environment), as it
agreed,
Kay Ramme - Sun Germany - Hamburg [EMAIL PROTECTED] writes:
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.
In which way do you think spirit is limited? The semantic
Thorsten Behrens wrote:
According to other people, spirit _is_ a DSEL (domain-specific
embedded language) - when given the choice, I prefer embedded DSLs
over external ones. :-)
Ohhh, from what I understood from others, I thought you 'd have to
construct a parser by C++ statements (using a
Hi Thorsten,
On Sat, Sep 24, 2005 at 23:18:24 +0200, Thorsten Behrens wrote:
hm. I'd profile a larger test case beforehand - spirit is a recursive
parser vs. yacc being table-driven.
A valid concern. IMHO yacc _will_ be faster anyway, the question is just
how much, and whether spirit would be
Kay Ramme - Sun Germany - Hamburg [EMAIL PROTECTED] writes:
Thorsten Behrens wrote:
According to other people, spirit _is_ a DSEL (domain-specific
embedded language) - when given the choice, I prefer embedded DSLs
over external ones. :-)
Ohhh, from what I understood from others, I thought
