RE: LuaJIT FFI/C++ binding, best approach?

["Steven Berry" <steven@...>]

> -----Original Message-----
> From: Mike Pall [mailto:mikelu-1107@mike.de]
> Sent: Monday, 18 July 2011 1:55 AM
> To: Lua mailing list
> Subject: Re: LuaJIT FFI/C++ binding, best approach?
> 
> Steven Berry wrote:
> > My current approach is to run my binding generator before compilation
> > and generate a cpp + lua binding file.
> > I use clang to visit each method and output the corresponding wrapper
> > function.
> 
> If you feel a bit adventurous, then you can directly bind to the
> C++ methods by using the mangled symbol names with the symbol
> renaming feature:
> 
> ffi.cdef[[
> void Test1_Method1(void) asm("_ZN5Test17Method1Ev"); ]]
> 
> The name mangling is very compiler/OS/CPU specific, though. And a few
> platforms use different calling conventions for methods, which is not yet
> implemented.

I didn't realise I could do that so I've actually hacked the LuaJIT code so
that ll_sym calls my own function to resolve the lookups.
This means that I don't need to worry about the mangled names although
calling convention is still an issue. 
I have non-virtual methods working fine but still need to get virtual
methods working.

It also allows me to use ffi on the ipad but without the jit using ffi is
about 8-10 times slower than the older binding style. 
Is this the expected performance gap? Would you recommend using non-ffi
bindings when jit is disabled?

> 
> >    C = ffi.C
> 
> local C = ffi.C
> 
> >    local Test1_index = {Method1 = function(__this, text)
> > C.Test1_Method1(__this, text) end }
> 
> You don't need the indirection with a Lua function:
> 
> local Test1_index = { Method1 = C.Test1_Method1 }

Thanks. That nearly halved the size of the lua file. I also realised that
   Test1 = function() return Test1_mt(C.Test1_new()) end
should have just been
   Test1 = function() return C.Test1_new() end



> 
> [Whenever I get around to parse a very restricted subset of C++, most of
> that will be superfluous. But don't hold your breath.]
> 
> --Mike
> 

For me personally, if FFI could handle basic classes as "interfaces" and
simple inheritance I would be happy :-)

Thanks,
Steven