lua-users home
lua-l archive

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

 On 9/27/2010 10:48 AM, Rob Kendrick wrote:
>  Sorry, but this is a completely wrong answer. The C interface is FAR
>  from trivial for many developers. I can use it fluently, and I still
>  wouldn't expose more than a few functions to Lua if I had to wrap
>  every one in the standard C interface.

Conversely, the number of people who turn up on #lua because they can't
get some automatic binding tool or C++ wrapper to do what they want is
astonishing.  Especially when doing it using the C API is often a 5-line
job, most of which is boilerplate.
Not anywhere near five lines if you're doing anything complex; just exposing one function? Sure. No point in adding complexity. For functions where I need variable parameters or similar, I still use the C interface. But if you're exposing nearly a hundred class member functions with varying parameters to Lua (e.g., Playground SDK)? I'd recommend a wrapper every time.

AND...the wrappers available leave some usability (or performance) to be desired. On this we can agree. :( In this particular case, the LuaPlus Call Dispatcher (which can be used without using LuaPlus, btw) is one of the easier to understand -- its interface looks very much like the standard Lua C interface, only it can takes class member functions and a "this" pointer instead of only global C functions.
(I'm very much of the opinion that the vast majority of a binding should
be done in Lua, exposing only function calls, not functionality, via the
And I want my C++ objects to be accessible in Lua, so I can still extend and process the objects at the C++ level. Different goals certainly result in different conclusions.