Re: ANN: Alien 0.3.1

[Enrico Tassi <gareuselesinge@...>]

On Thu, Feb 14, 2008 at 02:52:01PM -0200, Fabio Mascarenhas wrote:
> For non virtual methods (and assuming the object has a non-virtual
> constructor), yes, if the ABI for your C++ compiler passes the this
> pointer as an extra parameter. But if there is an uncaught C++
> exception you are in trouble...

IIRC another point where C++ will bite you is virtual methods.

If class A has a virtual method f and B inherits from A without
redefining f, there will be no B::f method in your .so files, thus 
your lua wrapper would have to know the class hierarchy and look for 
A::f instead.

And think about what will happen if you want your users to be able to
extend the class hierarchy, defining new Lua based classes on top of
existing C++ ones. Let say class C, inheriting from class B and
redefining f.  Then, think at what happens when you call a function g
expecting an objects of class A and using its f method. What the user
expects is to have C::f called, not B::f, but C++ knows nothing about
the lua class and it will dispatch to B::f.

IMO, you really need to wrap every C++ class with a technical class
redefining every virtual method and make that class eventually dispatch
to lua a virtual method invocation. This will make you binding not
pure-lua and bloated.

I've looked at wxlua some years ago, and the .so file was more than 2MB
(the bindings only), maybe they are doing something similar... If you
look at luagtk .so file, you will see that is 200K, since gtk is 
pure C with many introspective features there is no need to wrap
everything.

This was my conclusion after trying to bind fltk to lua using your idea
of mangling symbols on the fly and using dlopen to obtain the function
address and libffi to perform the function call... luckyly fltk is
exception free, thus I faced only half of the beast... and I was badly
defeated.

Cheers.
-- 
Enrico Tassi