 |
lua-l archive |
|
|
||
|
The main reason why this is not possible is that the standard Lua libraries create their own semantics and are not simply the export of an existing C library. For instance, the iolib is definitely not stdio; the strlib issimilar to string.h but allows strings to be indexed from the end and also handles embedded zeros; the math lib uses degrees instead of radians.
The fact that you write your own bits of C to provide a nicer interface to Lua doesn't stop you from wrapping them using an automated tool. I have written C support routines for the binding for the large package I'm scripting in Lua, but that hasn't stopped me using luaswig to access them. The same applies to the standard libraries: you can write the nice Lua-oriented front-end routines, and then wrap them. In any case, this discussion has veered off-course: the point should not be whether to use a wrapping tool or not (that's a religious problem!): the question is how to make it easiest to wrap C, and how to stop bugs and promote consistency. A tool generally makes it easier (you don't have to write any code!). Changing the C API along Edgar's lines would help to stop bugs and promote consistency (but writing no code is better there too). That's why I argue in favour of using SWIG, tolua or something similar all the time. However: 1. As already stated by John Passaniti, this may introduce overheads that are unacceptable for some uses (e.g. embedded systems). 2. SWIG is large, complex and not under your control, hence not a good choice for wrapping the standard libraries. tolua is perhaps too C++-oriented, but from what I know of it (I tried it before SWIG), it can probably cope with the standard libraries. I've thought about writing a simple tool, which I call luapp, that lets you mix Lua and C in the same file, and automatically generates wrappers so that you can call Lua from C and vice versa. It aims to work only with basic types (e.g. doesn't try to map Lua tables to C structs and arrays). This seems to me to give a very convenient way of programming when you want to wrap new code (as opposed to SWIG's ease of use for existing libraries). This applies to the standard libraries. It's also a good way of coding when you want to write some time-critical code in C. I have the details worked out, I think, if anyone's interested in further discussing this idea, but haven't had the (time x motivation) to code it yet (other than a basic parser that finds Lua and C functions in a .lc file). Its main task is to generate C wrappers for both Lua and C functions.
--http://sc3d.org/rrt/