lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


I'm new to this list, so beware :)

I've been experimenting with getting Lua 5.0-beta to work in C#. I used the standard C# Interop mechanisms to import all the lua_-functions from a DLL-version I created. The only problem I had were when I tried to access a C#-Function from a Lua script. The Interop-mechanism normally allows to pass C# Delegates (C# equivalent to function pointers) to other (native) functions, and they can treat it like a regular function pointer. The problem with Lua is, that Lua expects the cdecl-calling convention and delegates are marshalled as stdcall. This behavior can't be changed on the C# side, so I was wondering whether it would break too much code to have lua_CFunction use the stdcall calling convention ... maybe at least as something which can be changed at compile-time via a #define (LUA_CALLBACK_CONVENTION). I know that this might make existing binary packages incompatible and it also requires the user to tag his function wrappers with stdcall (or a #define symbol).

I mean, for me it is OK to have a separate version of Lua ... I'll probably wrap the entire Lua code into a managed C++ DLL. But, I just wanted to make the Lua community aware, that they could support C# (and possibly other .NET languages) very easily by changing the calling convention on lua_CFunction.

If this change won't make it into the Lua code-base I might have the time to provide a .NET Assembly if there is interest. I was thinking of wrapping the lua_State into a class 'State' in the Lua namespace. So, something like...

lua_State *L = lua_open();

would become

Lua.State L = Lua.Open();

I would also provide a 'compatability layer' which will look as much as possible like the standard C API and just lives in the Lua namespace. Sorta like (note, only difference would be the absence of pointers):

using Lua.C_API;

lua_State L = lua_open();

What do you guys think? BTW, if somebody has some pointers to C++ wrappers for Lua, then I might be able to look at those as well ... just to see how they approached this design-wise.

PS: I'm aware of the fact, that there'll be a Lua.NET down the road (I've seen the project page), but I need Lua now ... not in (many?) months.