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
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
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
Stephan writes:
I vaguely remember having discussed this before with Daniel Bölzle,
but neither of us can remember whether there were any serious problems
with it.
Well, will of course try this on a full build ;-)
Whether or not the constructor should be explicit might be a
question of
Stephan Bergmann [EMAIL PROTECTED] writes:
Third, the implicit option you proposed where you can implicitly use
xDerived for the up-cast.
That the third most closely mimics plain pointers does not
automatically qualify it as the best solution. Too much implicit
conversion can make code
Stephan Bergmann [EMAIL PROTECTED] writes:
I saw your patch yesterday and only had a quick glance at it. What I
do not understand is whether those few ambiguities/incomplete types
across OOo are related to the Reference change (i.e., whether the
Reference change introduces an incompatibility
Mathias Bauer [EMAIL PROTECTED] writes:
What I especially wouldn't like is the following situation: I have
written an extension that runs fine in, say, OOo 2.x. I also didn't use
any types that have been changed incompatibly in OOo3.0 but as this
release is announced to be API-incompatible my
Mathias Bauer [EMAIL PROTECTED] writes:
But that's the only safe way to do this, for them. BTW, telling from
past experience here: even if API stays compatible syntactically,
there's absolutely no guarantee that the semantics haven't changed,
and the extensions stops working anyway.
On Mon, Aug 25, 2008 at 02:49:56PM +0100, Andrea wrote:
I've tried to force a SIGSEGV, but even then, gdb stops but there is no call
stack available.
No idea...
Try another (newer) gdb version, if not done already. gdb had a
tendency to break on c++...
Cheers,
-- Thorsten
Emmanuel is not subscribed, Cc-ing.
Joachim Lingner wrote:
I have no idea what you mean with 'uno runtime environment exe for
windows', DCOM component etc.
There is, however, no particular type library available. OOo can only be
accessed via IDispatch.
Joachim
Hi *,
on the last ESC meeting, we had a little brainstorming about if and
how to deprecate OOo API. The 'if' was unanimously agreed upon,
for the 'how' we came up with the following thoughts:
API deprecation
===
See
11 matches
Mail list logo
