[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: C# and Lua
- From: Marco Kögler <marco.koegler@...>
- Date: Sun, 05 Jan 2003 16:48:36 +0100
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,
lua_State *L = lua_open();
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):
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.