[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: C++, pcall, and yield
- From: "Greg Falcon" <veloso@...>
- Date: Mon, 17 Apr 2006 17:49:04 -0400
On 4/17/06, Mark Hamburg <mhamburg@adobe.com> wrote:
> Will LuaJIT work when Lua's exception mechanism is redefined to use C++? Or
> does the stack switching confuse the C++ exception mechanism?
>
> I know this is a likely issue with Apple's Objective-C/Cocoa runtime unless
> one hacks in to swap private globals appropriately. Most C++ runtimes don't
> even expose that information.
>
> Mark
This kind of concern is the only reason Coco wasn't suitable for my
needs. As far as I could tell from man pages and Google searching,
POSIX's ucontext interface makes no claims about exception handling or
other C++ features. So my fear was I'd use it, it would appear to
work, but then my code would be irreparably unportable to other Unix
flavors. Coco can also implement C coroutines using inline assembly
or hand-modifying a jmp_buf structure for use with longjmp, but of
course these measures have even more glaring portability concerns.
For Windows, Coco uses the fibers interface to create coroutines,
which is documented to work with C++ exceptions, though there appear
to be some MSDN bloggers who consider this abuse. (Doesn't seem like
abuse to me.)
I really like Lua's approach to C/C++. The benefit of using of
try/catch for errors in C++ is easily misunderstood. Its benefit is
not that it will catch unhandled exceptions, and its use is more than
just a "let's use this because it's there" measure. Because try/catch
property unwinds the stack (where setjmp/longjmp doesn't), you can use
C++ objects inside your Lua C++ functions, and they will be property
destructed if an error is thrown (or, in this patch, if a yield occurs
in your resumable Lua C++ function). That's something I'm not at all
ready to give up. :)
Greg F