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 8:41 PM
> To: Lua mailing list
> Subject: Re: LuaJIT FFI/C++ binding, best approach?
> 
> Steven Berry wrote:
> > I have non-virtual methods working fine but still need to get virtual
> > methods working.
> 
> Most of the C++ compilers use a virtual table. This is pointed to by a
hidden
> field at the beginning of the struct/class. The layout of the virtual
table
> usually follows this convention:
> 
> http://www.codesourcery.com/public/cxx-abi/abi.html#vtable

If I have the time I might try to get virtual methods working etc but it's
not a very high priority at the moment. 
A fair amount of effort to save a wrapper function...And I guess if you do
ever support C++ you're going to have to do this anyway.

> 
> > 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?
> 
> Yes, the FFI has been designed with a JIT compiler in mind. It's rather
slow
> without the JIT compiler. So you can still use it for convenience (ad-hoc
calling
> any C function), but probably not if you require performance (calling a C
> function many, many times).
> 
> BTW: Unlike iOS, the JIT compiler works fine on Android. ;-)

Which is one reason I'm using FFI bindings  :-) But I would like reasonable
performance on the iPad also.

> 
> > 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
> 
> Umm ... Test1 = C.Test1_new

Yes, that would be simpler again. I can't believe I missed that...
I do however use the function in some cases to setup default values eg.
  Test1 = function(a,b) if b == nil then b = 'something' end return
C.Test1_new(a,b) end
but there might be a better way to do that also. 
Anyway, I have fixed the simple cases to now just use Test1 = C.Test1_new. 

> 
> > > [Whenever I get around to parse a very restricted subset of C++,
> > > most of that will be superfluous. But don't hold your breath.]
> >
> > For me personally, if FFI could handle basic classes as "interfaces"
> > and simple inheritance I would be happy :-)
> 
> The problem is that everyone would like to have a different subset of C++
> supported. This will add up. Also, even indirect use of complex libraries
(e.g.
> inheriting from a Boost class) kills that approach.
> 
> I'm not so sure whether it's possible to define a useful subset of
> C++ which would still make a majority of users happy. That doesn't
> mean I won't try (I already have a potential sponsor for this), but I
really don't
> want to add an ineffectual solution.
> 
> --Mike
>