On Tue, Jan 20, 2009 at 7:07 PM, Ariel Manzur
<puntob@gmail.com> wrote:
Hi.
On Tue, Jan 20, 2009 at 11:13 AM, Anders Backman <andersb@cs.umu.se> wrote:
> - LuaBind
[...]
> * Full support of virtual methods
do you know if this is documented? I didn't see anything on their
manual, but I'd love to see how this kind of thing is implemented.
Hm, I guess it was only one way.
I implemented this together with tolua a while back though. For me it was important that I could create a class in lua, implement the virtual method, register the class to a listener, and then this (virtual) method was executed from C++.
To do this, I had to implement a class:
namespace {
LuaClass: public Class {
bool virtual keyboard( int key, int modkey, float x, float y, bool keyDown )
{
vrutils::LuaCall lc(m_lua, "namespace::LuaClass", this, "lua_keyboard", false);
if (!lc.isValid())
return false;
// Rest is arguments
lc.pushNumber(key);
lc.pushNumber(modKey);
lc.pushNumber(x);
lc.pushNumber(y);
lc.pushBoolean(keydown);
if (lc.call(1)) // Make the call return 1 value
error("keyboard", "Error during execution of luafunction lua_keyboard");
// Is there a value on the stack?
if (!lua_gettop (m_lua))
return false; //error("keyboard", "Lua function call does not return a value, expecting bool");
// Is there a value on the stack?
if (!lua_isboolean (m_lua,-1))
return false; //error("keyboard", "Lua function call does not return a value, expecting bool");
// Get it
bool f = tolua_toboolean (m_lua, -1, 0) ? true : false;
lua_pop(m_lua, 1);
return f;
}
};
}
This could of course be automated through xml2cpp and tolua...
SO whenever tolua encounters a virtual method, it creates the above code automatically and implements a class which can be used from lua:
test.lua:
listener = namespace.LuaClass:new();
function listener:lua_keyboard(key, modKey, x,y,down)
print("key is: "..key)
end
listenerManager:add( listener )
Now the listenerManager can trigger the listener, and it doesnt matter whether the virtual method (keyboard/lua_keyboard) is implemented in c++ or Lua, it will be executed no matter what.
The drawback is that I dont think it will work to have the same name (or perhaps it will?) of the method keyboard in lua...I dont recall why I had to add the lua_ prefix.
Nevertheless, this worked just fine, except for:
1. I had to manually create .pgk files for all classes. Whenever the C++ classes where changed, I had to manually update the .pgk files, a mess when you wrap external (not written by us) toolkits.
2. Any method that required virtual calling in lua (as described above) required that I had to implement this derived LuaClass...however a very mechanic process which could be automated.
Comments?
/A
> - tolua++
> * Do not support virtual methods in lua
http://lua-users.org/wiki/ImplementingVirtualMethodsWithToluapp
this should work (if not, I'll fix it).
> - luaQT (right now specialized for QT, but...)
> * Parse .h files of the target API
> * Require you to filter out unwanted classes, but after that its automatic
> * Does not handle namespaces
If I'm not mistaken, this is called 'lqt' (unless this is the "full"
name). Not to be confused with lua_qt wich is a tolua++ binding of
qt4.
Yes lqt was the name, sorry.
> Right now yet another way would be to use cpp2xml (like luaQT) and generate
> cleaned up .pkg files and run those through tolua++. However this would not
> give me support for virtual methods, this would be added to tolua++...
I've been wanting to do something like this for a while, but I haven't
found the time. It's either xml -> pkg -> tolua, or just make tolua
capable of directly parsing the xml files.. generated pkg files would
probably be the easiest way, if you can handle the extra layer of
hacking (running the xml parser on the makefiles, debugging the
intermediate .pkg files, etc).
The .pkg files would as you say work for debugging. Just getting the generated cpp files would in most cases not reveal structural problems... So having this middle layer is probably a good thing.
And it would solve the main problem with the solution to implement
virtual methods on lua, which is acquiring all the methods at all
levels of inheritance. This would probably make the qt bindings _huge_
tho.
You mean each and every virtual method in QT would be bound to this code...
But isnt that the problem already in lqt?
>
> Looking for quite some feedback because I know this is a hot issue!
>
> Cheers, Anders
>
>
