Mike Pall wrote: > Ok, so I gave up (for now). Well, you summed it up pretty well. This is the reason why I think it would be useful to first try to bind C++ libraries using just plain C FFI, what I'm trying now. I'm able to sail past the problems you mentioned up to now by a combination of Lua side declarations + some extra C++ binding code (not too much) so that C++ objects become basically opaque FFI structs. Not very elegant, but it seems to work. > I'm sorry, but I guess everyone will have to live with their > workarounds for C++ support for a little longer. I shelved > the code -- it's very brittle and adds way too much > complexity within the current development timeframe for > LuaJIT 2.0. I might give it another go _after_ LuaJIT 2.1 has > gotten up the ground, though. I'll be watching it closely :)) > BTW: I'm still considering the enum change (always box them), but > I'll have to think this through first. I really need 2 things to make my C++ bindings work reasonably on the current FFI: 1) the "enum change" you just mentioned, and 2) the "__cast" (or whatever name you can give it) metamethod on the destination type to support implicit type casting. That would remove all the ugly hacks from the 'lj_cconv_ct_ct'. Any chance on the second issue? -- Janis