lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

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

Could this be beatified somehow?

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 =,2,3);
v3.__gc = v3.delete
cam:setPos( v3 );

one could write:

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

What do you think?

#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
 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

   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();


And this is the script I use to test it:


print("loaded test")

local a =
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 =

-- 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 =
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 = << 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 <> 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