Luabind is a library that helps you create bindings between C++ and Lua. It has the ability to expose functions and classes, written in C++, to Lua. It will also supply the functionality to define classes in lua and let them derive from other lua classes or C++ classes. Lua classes can override virtual functions from their C++ baseclasses. It is written towards Lua 5.x, and does not work with Lua 4.
It is implemented utilizing template meta programming. That means that you don't need an extra preprocess pass to compile your project (it is done by the compiler). It also means you don't (usually) have to know the exact signature of each function you register, since the library will generate code depending on the compile-time type of the function (which includes the signature). The main drawback of this approach is that the compilation time will increase for the file that does the registration, it is therefore recommended that you register everything in the same cpp-file.
Luabind is released under the terms of the MIT license.
Copyright Daniel Wallin, Arvid Norberg 2003. Extracted from http://www.rasterbar.com/products/luabind/docs.html
I forked the project since it seems abandoned (latest commit from January 2012 on the 0.9 branch) and I ran into certain bugs which needed fixing (see commits).
This should actually have been forked from rpavlik/luabind: I cherry-picked most commits from there. Additionally, many commits from fhoefler/luaponte are incorporated (as the are in rpavlik's fork). Thus, feel free to do the same with my fork.
In the following two sections, the improvements over the latest official luabind release (0.9) are described.
Destroyed objects now have their metatable unset. Previously, one could easily cause segmentation faults and other undefined behavior by accessing destroyed objects from luabinds
__finalizeor Lua 5.2's
__gc. Now you can simply check with
getmetatable(obj), and if you forget, you get an ordinary, well defined Lua error instead. Commit a83aa.
The Lua part of a
wrap_basederived class randomly got lost after a few garbage collection cycles due to errors in the implementation of the internal
weak_refclass. Credits for the fix go to Max McGuire who posted a fix on luabind-user in 2010. Commit a3a400.
The error message displayed when a function could not be called from Lua with the provided arguments sometimes only contained the function signatures but not the actual error message. mrwonko's commit 9d15e0 (and previous).
call_functionwith a return type but not using it resulted in a call to
std::terminateif the called function produced an error and a C++11 compliant compiler is used. Commit 81bdcb.
Luabind failed to recognize Lua numbers correctly on MSVC x64. Commit c9582c.
Luabind failed to compile on Clang. Commit 4555b2.
- CMake replaces the broken Jamfile as build system (including installation
and test support).
FindLuabind.cmakefile is also provided, as well as
- A bit of C++11 support:
- A new (C++) function
set_package_preloadcan be used to register a (loader) function to be called only if it is
required from Lua. rpavlik's commit 3502e9.
- Modules can now register everything to arbitrary tables
luabind::objects). fhoefling's commit dd4a16. This plays together very nicely with
- The modulo operator
%can now be exported to Lua. rpavlik's commit 855b4a and the following.
class_infocan now handle actual classes as arguments. Previously it could handle only objects of luabind classes. rpavlik's commit c2ee1f.
Additionally, the removal of many lines of death code, also unused (parts of) member variables and other minor improvements make luabind generally (a little bit) faster and less memory hungry.
Many compiler warnings have also been fixed. The remaining (irrelevant) ones are silenced, so the build should be completely warning- (and of course error-)free on Clang, g++ and MSVC.
This fork is fully source (API) compatible to the original luabind library, but not binary compatible.
A word on the branch names
First I worked against the 0.9 branch but then decided to rename it to master, since it actually has become the master branch of development in this fork. The original master branch is now named old-master.