On Thu, Oct 22, 2015 at 1:09 AM, Philipp Janda <siffiejoe@gmx.net> wrote:
[...]
You suggested "that this be incorporated into Lua's official source." So this concerns more than just your implementation.
Fair enough. So let's look at our options. Today, Lua's source code, out of the box, supports three major modes:
Pure C: The Lua library, the host, and any other library interacting with Lua are written in standard compliant C and are built as such.
Pure C++: The Lua library, the host, and any other library interacting with Lua are written in standard compliant C++ and are built as such.
Implementation specific: none of the above.
Now I have a particular need: my host is written in and built as standard compliant C++, I want to use Lua, and I want them to interoperate with Lua libraries written in standard compliant C (and built as such, for reasons indicated in the original post). Requirements re-formulated:
Hybrid mode: Lua libraries, written in and built as standard compliant C or C++, shall all interoperate with Lua (no requirement as to whether it is C or C++).
There have been suggestions in the thread to relax this requirement by replacing "standard compliant C++" with, essentially, "crippled C++". That is not being considered, but it may be further required that C++ libraries shall not throw exceptions at Lua except by calling lua_error().
The pure C and pure C++ options do not work by definition. So I am left only with the "implementation specific" option given Lua's current source code, whether you like it or not.
But even if I am in the "implementation specific" area, I still need to meet my requirements. Unless I have missed something big, the only reasonable course of action here is to build Lua as standard compliant C++, which will interoperate properly with the C++ libraries, but that will not interoperate with C libraries at all because of the language linkage, as explained originally. Lua's current source, out of the box, makes this impossible regardless of my implementation. This is the problem that I suggested in the original post should be fixed.
The change as suggested originally, however, has a drawback: it will be applied unconditionally in the pure C++ mode, making it implementation specific. This could be controlled by another define, say CPP_HYBRID, with the code modified as follows:
#if defined(__cplusplus) && defined(CPP_HYBRID)
#define LUA_APIextern "C"
#define LUA_LINKAGE extern "C"
#else
#define LUA_APIextern
#define LUA_LINKAGE
#endif
LUA_LINKAGE is to be injected into the definitions of the function types such as lua_CFunction as follows:
LUA_LINKAGEtypedef int (*lua_CFunction) (lua_State *L);
So the hybrid mode, when desired and supported by the implementation, can be invoked via a single define, without affecting other modes. Comments?
