lua-users home
lua-l archive

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

I'd like to give a bit feedback from another point of view:

In our little hobbyist VR/game engine we use a mix of Luabind
with additional manual bindings when Luabind doesn't cut it
or we need to extend the bindings to bring it closer to the
Lua kind of programming (for example, Lua iterators).

Works pretty fine so far.

Obviously, if you have a working reflection mechanism it may make
sense to bind this. (We do this for object properties and
object events.)

As Luabind doesn't cover all our needs we have to extend it,
though, up to now it wasn't necessary to modify a single
line of Luabind itself. It was all be done easily using the native
Lua C API. On the other hand, up to now, our features weren't very
complicated to implement.

Cheers,
Stephan

Daniel Collins wrote:

I was just wondering how most people here bind there native code to lua.


On my first major project with Lua (a mobile phone game with
downloadable content, unfortunately never released) I wrote all the
binding code by hand. In other smaller "personal use" projects since
then I have also written all the binding code by hand.

On a recent project (binding C++ savegame editing code for Darklands, a
1992 RPG set in medieval germany with a cult following today) I decided
to try my hand at automated binding code generation. 
I first tried tolua, which worked brilliantly but for one thing:
exceptions. So I ended up with a modified version of tolua++ 1.0.91
(from www.cegui.org.uk) that has support for exception handling.
Unfortunately it also has a bug where fixed size char arrays (eg: char
charArray[20];) generate incorrect parameter checking code for setting
the value (it tries to make sure the argument is a table rather than a
string). 
So my experience has been that hand-binding and automated binding both
have benefits and drawbacks:

Hand-binding:
	++ Absolute control over how the binding occurs. If I need
exception handling, I can create exactly what I need.
	+ Forces a solid knowledge of the C API. Some may see this as a
negative.
	+ Much easier to read and debug.
-- Slow to create. - Harder and slower to update when either the native code API or 
the exported Lua API changes.

Automated:
	+ Fast.
	+ In theory, should be less error prone.
	+ Very fast updating of the binding code when the underlying
native code API changes.
	-- Leaves me dependent on the capabilities of the binding tool.
This can manifest as a hunt for a different tool, or in warping the
native code API to accommodate the needs/limitations of the binding
tool.

That last point is to me the biggest drawback of automated code binding.
I don't like having to modify the native code API just to suit the
binding tool, especially since the C++ code is also used by other C++
projects. I also don't like being dependent on the tool's functionality
for features I know I could do by hand.


I don't know which method I would use in future projects. I suspect that
the larger the native API the more the speed gains of automated binding
would outweigh the fine control that hand written binding code gives.

In my current situation, I might just hand write the bindings for those
items that cause problems for tolua++.

So what are the thoughts and experiences of others here on this issue?

- DC