lua-users home
lua-l archive

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

> -----Original Message-----
> From: Mike Pall []
> 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
> field at the beginning of the struct/class. The layout of the virtual
> usually follows this convention:

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
> without the JIT compiler. So you can still use it for convenience (ad-hoc
> 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
> >    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
> 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