 |
lua-l archive |
|
|
||
|
Am 21.10.2015 um 15:45 schröbte Viacheslav Usov:
On Tue, Oct 20, 2015 at 7:33 PM, Philipp Janda <siffiejoe@gmx.net> wrote: [...] You shouldn't throw exceptions from `extern "C"` functions, especially ifreal C code is involved. So the whole point of compiling Lua as C++ becomes moot.This is false. Oh, and "real C" is not defined, too.
"Real C" for the scope of this thread is defined (by me) as code compiled by a C compiler in contrast to an `extern "C"` function that is compiled by a C++ compiler. E.g. gcc by default does "The Right Thing" (`-fexceptions`) for C++ code, but not for C code. That's why I made the distinction. In theory it isn't needed, because the behavior is undefined by the C++ and C standards in both cases.
The current C++ standard states, in clause 7.5.1: "Some of the properties associated with an entity with language linkage are specific to each implementation and are not described here". Subsequent clauses on language linkage do not introduce any exception-related restrictions.
Meaning the C++ standard doesn't define those properties.
So exception propagation over C/C++ boundaries is both standard compliant and entirely implementation specific.
Any C++ compiler/implementation is allowed to define behavior that is undefined by the C++ standard.
[...]So if you have C code *and* C++ code, and both use `lua_CFunction`s, your only standards compliant option is to compile Lua as C and use `extern "C"` in your C++ code for your binding functions.This is not the only option. One can still compile Lua as C++ with lua_CFunction and other function types defined as extern "C".
`lua_pcall()` (C++) -> Lua code -> `lua_CFunction` (`extern "C"`) -> `lua_error()` (C++) -> `throw`. So we have undefined behavior again because the exception passes language boundaries. Whether it works in practice depends on compiler/implementation, command line flags, whether it's "real C" code the exception is passing through, etc.
Cheers, V.
Philipp