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

[Mike Pall <mikelu-1107@...>]

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

> 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. ;-)

> 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

> > [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