[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: PATCH: Fully Resumable VM (yield across pcall/callback/meta/iter)
- From: David Given <dg@...>
- Date: Tue, 15 Feb 2005 16:48:00 +0000
On Tuesday 15 February 2005 16:18, David Jones wrote:
> In particular when longjmp is
> invoked it is allowed to trash any local variable declared in the
> function that called setjmp (the one to which we are jumping), unless
> that variable is declared volatile.
You are, of course, absolutely right.
(It turns out that gcc *does* have special knowledge of setjmp(), but only
enough to warn you about non-volatile variables --- it doesn't stack and
unstack stuff for you, which is really irritating because the code I'm
working on right now requires it. Does anyone know any workarounds?)
> C++ exceptions are _designed_ to be slow aren't they? It was a
> specific goal when designing C++ that C code, when compiled under a C++
> compiler, be no slower; and it was specifically intended that the
> runtime design of exceptions be slow in order to do make this so.
Given that C variables don't need destruction, then I'd assume that since any
compiler knows at any point what variables in scope need their destructors
called, the compiler could emit stack wind-up code to do whatever's
necessary... a bit bloaty, perhaps, but not necessarily slow. Every time a
variable went into scope the compiler would have to adjust the wind-up code.
This would only impact performance for variables that had destructors.
Is this actually how C++ compilers do things? I've had a look at gcc's output
code, and it's totally incomprehensible.
Incidentally, the original poster said that he was using gcc, not Visual C++,
which is what I originally thought. This surprises me; what optimisation
flags are you using?
+- David Given --McQ-+ "I must have spent at least ten minutes out of my
| email@example.com | life talking to this joker like he was a sane
| (firstname.lastname@example.org) | person. I want a refund." --- Louann Miller, on
+- www.cowlark.com --+ rasfw