Re: "Official" binding library

[Patrick Rapin <toupie300@...>]

Since we are sharing our binding methods, I can also explain the
methods used in my two major Lua applications:

1) In LuaDura, as explained in the last Lua Workshop at Frick, a
custom Perl script parses all C++ class headers of the printer
firmware, and generates a plain text file describing the public
virtual member functions and their types. That text file is then
embedded *inside* the printer firmware. So the "binding" here is
somewhat particular: LuaDura can retrieve that text file through USB
and generate objects mapping at runtime. There is therefore no
compile-time C++ binding, but a sort of runtime one implemented in
pure Lua, more similar to a FFI library.

2) In Pipeline (our image processing library), we only needed to bind
the *constructors* of the C++ classes, plus of few methods for some
key classes.
All Pipeline classes derive from a base class implementing a reference
counting mechanism, using Retain() and Release() members (inspired
from Apple's Cocoa framework).
The binding works as follows: a modified version of the previous Perl
script parses all C++ header files and looks for public constructors.
It then generates code like the following for each constructor (here :
CApplyGammaRGB class)

static int new_CApplyGammaRGB(lua_State* L)
{
	BeginConstructor(L, "CApplyGammaRGB", 1);
	double* arg1 = getArrayArgument<double>(L, 1, false);
	CApplyGammaRGB* obj = new(RETAIN) CApplyGammaRGB(arg1);
	return pushObject(L, obj, "CApplyGammaRGB", "CProcess");
}

There are a few helper template functions like getArrayArgument<T>
aided to retrieve correct typed values.
All constructor functions go into a library table named "new" (yes, I
know, this is peculiar), so to instantiate the previous class, you
only need to write :
local obj = new.CApplyGammaRGB {1.5, 2.0, 2.0}.
The special name of the library makes the code look a bit like the
underlying C++ language...
As the __gc metamethod for all objects calls Release(), the memory
deallocation is automatic.
-------
In conclusion, for neither of those two projects would a generic
binding library like LuaBind fit. The needs were too special.
I am pretty sure however that there *are* projects for which binding
libraries are the best solutions.