[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: RE: LuaJIT FFI/C++ binding, best approach?
- From: "Steven Berry" <steven@...>
- Date: Mon, 18 Jul 2011 21:27:51 +1000
> -----Original Message-----
> From: Mike Pall [mailto:email@example.com]
> 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
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
> want to add an ineffectual solution.