|
On Jul 27, 2009, at 4:47 AM, Juris Kalnins wrote:
On Mon, 27 Jul 2009 12:55:23 +0300, Juris Kalnins <juris@mt.lv> wrote:Lua error mechanism only require setjmp/longjmp, not C++ exceptions.Are you sure -fexceptions is needed for setjmp/longjmp to work ? IIRC -fexceptions generate data needed for destructors to be called, whichsetjmp/longjmp and thus Lua error mechanism do not need.But c++ does need it. It runs destructors on function exit. You cannot simply discard stack frames in C++. (And see above example for why it is bad for C, too).Sorry, this reply was unnecessarily terse. To clarify: problem is not that setjmp doesn't work with -fno-exceptions, but that C++ throw/catch cannot be used with -fno-exceptions, and thus any Lua exception that unwinds C++ stack frame is an error. In other words, it is not possible to call most of Lua API from C++ functions that have non-trivial local variables, if Lua doesn't use C++ throw for exception handling.
You can address that by only using lua_pcall to call from C++ to Lua and being prepared for any errors that come back. Or you could if you didn't have to also worry about all of the memory and parameter errors that will then necessitate going though lua_cpcall. And unfortunately, lua_cpcall is moderately expensive since it needs to build a new function object...
This brings up an old thought I had when I last looked at trying to bottleneck things through lua_cpcall: Would it be useful to have a light C function data type that would have no environment or upvalues and which could be stored in a TVALUE without allocating storage?
Mark