Re: lqt: Qt bindings update

Ok a few more comments:

Im starting to test to export a bunch of classes, and it works for quite a lot of the code, problems and ideas are listed with # below:

#1 obj.__gc = obj.delete -- scope deletion

tolua has adopted new() // c++ responsibility to dealloc, and new_local() // garbage collection.

This would double the number of constructors, but Its a lot more clear and consistent.

For example classes that almost always are used only on stack are:

small vector classes, matrices, quaternions etc...

so instead of writing:

local v3 = osg.Vec3.new(1,2,3);

cam:setPos( osg.Vec3.new_local(1,2,3) );

#2 I did not get delete to work at all:

This is the class declaration:

#ifndef AA

#define AA

#include <iostream>

namespace test {

class A

{

public:

A() { std::cerr << "A::A" << std::endl; }

~A() { std::cerr << "A::~A" << std::endl; }

void doFunc() { std::cerr << "A::doFunc()" << std::endl; func(); }

virtual void func() { std::cerr << "A::func()" << std::endl; }

class B

{

public:

B() { std::cerr << "B::B" << std::endl; }

~B() { std::cerr << "B::~B" << std::endl; }

void do_something() { std::cerr << "B::do_something()" << std::endl; }

};

void useB(B* b) { b->do_something();

}

};

}

#endif

And this is the script I use to test it:

#!/usr/bin/lua

require'test_lua'

print("loaded test")

local a = test.A.new()

a:delete() -- When I get to the delete function for test.A it receives a NULL pointer and hence delete is never called.

#3 Tried virtual methods

local a = test.A.new()

-- implement virtual method

a.func = function(o) print("lua func") end

a:func() << lua: attempt to index a userdata value

a:doFunc() << lua: attempt to index a userdata value

#4 The virtual method is not exported to lua so:

local a = test.A.new()

a:func(); -- lua: t01.lua:12: attempt to call method 'func' (a nil value)

#5 nested classes as I indicated before does not work:

local b = test.A.B.new() << lua: t01.lua:7: attempt to index field 'B' (a nil value)

But its looking promising. Of all the C++/lua bindings I have used so far this has the most potential for scalable export of code...

#6 library naming convention

Right now the naming convention of the dynamic library is perhaps not optimal.

If I export a library named osg, it would create a dll file named osg.dll, which would directly collide with the ORIGINAL osg.dll (that comes with OpenSceneGraph).

Therefore I would suggest that the generated wrapper dll should have a name of osg_lua, lua_osg, luaplugin_osg or alike,

so this would also change require 'osg' to require 'osg_lua'

Also, some library use 'd' as a postfix for debug versions of the library, however this does not work with the require function of lua, or?

Anyway, having a unique dll name is important to avoid clashes.

Sorry for a long posting!

On Wed, Jan 21, 2009 at 1:59 AM, Mauro Iazzi <mauro.iazzi@gmail.com> wrote:

> What about destruction? Who is responsible for deallocating objects?

C++ manages everything by default. You can change this by

obj.__gc = obj.delete -- delete on collection
obj.__gc = nil -- do not delete on collection
obj:delete() -- explicitly delete. the object is now invalid