Well, I lied. This isn’t step by step but I believe this commented source code dump should be more illustrative than any tutorial I’ve read, here we go
5 Responses to “Binding C++ classes to Lua: a step by step example for beginners”
Hi! Nice example! Been trying to find some information on how to bind c++ and lua manually. Do you have any examples on how to expose a Foo allocated in c++ to lua? Thanks a bunch!
The above method already exposes Foo from C++ to Lua. You can see the line “Foo:add(3, 4)”. The “Add” method is written in C++, not Lua.
And then I added “Foo:speak()” from within Lua. That means I can extend a C++ class within Lua.
To understand how that worked, it is a good idea to really dive into metatables and understand how they work from the guts. Then everything should fall into place.
Now, in real life, you would probably want to use a framework to bind C++ to Lua instead of coding it by hand like above.
If you application is not performance critical (e.g. desktop), go with Luabind. It’s easy and elegant.
For mobile games, try SWIG or toLua++.
If you need absolute speed or don’t want to introduce a dependency just to bind a couple of classes, you can use the method above.
Hi there! Things are a bit clrearer now, but I’m still having a bit to learn about how to manage resources. I am trying to expose data to lua functions for manipulation, but I don’t want lua to free the resources. I want to be able to allocate objects in C++, send them to lua and then continue using them in my C++ application. If I allocate the userdata in lua, lua should gc it when done.
Using a framework is nice i guess, but I want to learn a bit more about the inner workings before I use a tool.
The trick line here is this “Foo ** udata = (Foo **)lua_newuserdata(l, sizeof(Foo *));”
Notice that the userdata is a pointer. So the actual object allocated in C++ will never be GC’ed by Lua. If Lua loses references to the object, the Lua GC will deallocate the pointer — an integer
Lua’s runtime has no knowledge of the C runtime such as how the heap is arranged and what not, so Lua will never GC anything from C++. The GC can only deallocate what it allocated in the first place Remember, deallocating things in C++ must ultimately needs to calling “delete” or “free()”, and your Lua code can’t do that.
Therefore, in the above code, I allocate the object in C++ and the object always “stays in C++”
What about the idea of allocating the object itself in Lua? It is a bad idea because it is clumsy for C++ to obtain a pointer to that object. Remember that many GC implementations actually move the object in memory so if the C++ code saved a pointer to the object allocated in Lua, it may go kaboom when the pointer reference has been made obsolete by a compacting GC. What people do in languages like C# is to ask the GC not to move something (“pinning it”) – which makes it quite clumsy and makes GC’s algorithm very complicated.
So again the above should already satisfy your objective
I’m experimenting with a FooWrapper that wraps a shared_ptr, and it seems to solve the whole memory management problem. But I am not sure I want to use boost When lua decides to kill the LuaWrapper*, the destructor will dereference the shared_ptr and as long as i’ve got a reference in my c++ code, all is well.
This way I can create the same type in lua and c++ and not worry about it dieing all of a sudden.
It’s a robust solution, but not the leanest.
Thanks again. I’ve learnt alot from your code and comments. The web is littered with lua embedding tutorials that people write the moment the start to grasp this. It’s honestly a sickness of the web
Hi! Nice example! Been trying to find some information on how to bind c++ and lua manually. Do you have any examples on how to expose a Foo allocated in c++ to lua? Thanks a bunch!
Comment by uggwar on April 19, 2012 at 6:31 pm
@uggwar
The above method already exposes Foo from C++ to Lua. You can see the line “Foo:add(3, 4)”. The “Add” method is written in C++, not Lua.
And then I added “Foo:speak()” from within Lua. That means I can extend a C++ class within Lua.
To understand how that worked, it is a good idea to really dive into metatables and understand how they work from the guts. Then everything should fall into place.
Now, in real life, you would probably want to use a framework to bind C++ to Lua instead of coding it by hand like above.
If you application is not performance critical (e.g. desktop), go with Luabind. It’s easy and elegant.
For mobile games, try SWIG or toLua++.
If you need absolute speed or don’t want to introduce a dependency just to bind a couple of classes, you can use the method above.
Have fun!
Comment by kizzx2 on April 19, 2012 at 10:45 pm
Hi there! Things are a bit clrearer now, but I’m still having a bit to learn about how to manage resources. I am trying to expose data to lua functions for manipulation, but I don’t want lua to free the resources. I want to be able to allocate objects in C++, send them to lua and then continue using them in my C++ application. If I allocate the userdata in lua, lua should gc it when done.
Using a framework is nice i guess, but I want to learn a bit more about the inner workings before I use a tool.
Thanks for your time!
Comment by uggwar on April 20, 2012 at 2:23 pm
@uggwar
The trick line here is this “Foo ** udata = (Foo **)lua_newuserdata(l, sizeof(Foo *));”
Notice that the userdata is a pointer. So the actual object allocated in C++ will never be GC’ed by Lua. If Lua loses references to the object, the Lua GC will deallocate the pointer — an integer
Lua’s runtime has no knowledge of the C runtime such as how the heap is arranged and what not, so Lua will never GC anything from C++. The GC can only deallocate what it allocated in the first place Remember, deallocating things in C++ must ultimately needs to calling “delete” or “free()”, and your Lua code can’t do that.
Therefore, in the above code, I allocate the object in C++ and the object always “stays in C++”
What about the idea of allocating the object itself in Lua? It is a bad idea because it is clumsy for C++ to obtain a pointer to that object. Remember that many GC implementations actually move the object in memory so if the C++ code saved a pointer to the object allocated in Lua, it may go kaboom when the pointer reference has been made obsolete by a compacting GC. What people do in languages like C# is to ask the GC not to move something (“pinning it”) – which makes it quite clumsy and makes GC’s algorithm very complicated.
So again the above should already satisfy your objective
Comment by kizzx2 on April 20, 2012 at 8:41 pm
I’m experimenting with a FooWrapper that wraps a shared_ptr, and it seems to solve the whole memory management problem. But I am not sure I want to use boost
When lua decides to kill the LuaWrapper*, the destructor will dereference the shared_ptr and as long as i’ve got a reference in my c++ code, all is well.
This way I can create the same type in lua and c++ and not worry about it dieing all of a sudden.
It’s a robust solution, but not the leanest.
Thanks again. I’ve learnt alot from your code and comments. The web is littered with lua embedding tutorials that people write the moment the start to grasp this. It’s honestly a sickness of the web
Comment by uggwar on April 20, 2012 at 9:27 pm