RE: LuaJIT2 crash reporting an error in FFI metamethod

["Janis Britals" <jbritals@...>]

> I'm also curious how do you handle the mangled names.
> 
> There was many years ago a real "C" binding for the Qt 
> library, but has been abandoned since.

I was thinking of using a "demangler" on the Qt library in question (like
QtCore4) and matching the demangled symbol with the member function. This
would give me the mangled version that I could put in the bindings module.
This should be possible to automate to a great degree using Perl scripts.
However I haven't gotten yet around to writing these scripts so currently
I'm using very thin interface layers wrapping C++ method calls in their
'extern "C"' equivalents. It is a good enough solution in itself, though
less elegant.
 
> On 3/9/2012 12:37 PM, Leo Razoumov wrote:
> > On Fri, Mar 9, 2012 at 13:05, Janis 
> Britals<jbritals@xs4all.nl>  wrote:
> >>
> >> I'm switching my current Qt Lua bindings to LuaJIT's FFI and am 
> >> amazed at how well it works. I can throw out loads of C++ binding 
> >> code and replace them with small and elegant Lua chunks.
> >>
> >
> > I am curious how do you access data members in  C++ classes with 
> > virtual methods by means of  FFI?  Due to presence of virtual table 
> > memory layout of such objects is different from C struct 
> POD that FFI 
> > expects.

Direct access to data members is only necessary in cases of simple data
structures with value semantics (like QPoint, QChar, etc). These are safe to
treat as PODs from the point of view of FFI.
All Qt classes with virtual methods are "opaque" with regard to FFI, i.e.
they are passed only by pointer (or reference which is the same thing) to
functions of Qt library. You never access their "members" directly.