Re: Lua - C++ Bindings

[Mauro Iazzi <mauro.iazzi@...>]

> For basic types is straightforward, but what we should do with
> instances of classes ? The problem is basically C++,  it's far too
> flexible, you can have different kind of constructors, copy operators,
> destructors, public, protected, or private methods, and so on.

I second that.
In particular you cannot understand how an API should be used just by
looking at the public code. The simplest example is pointers.
This is why lqt simply does not support using pointers as array
arguments. They are supposed to be references to just one instance.
Yet, I think this is a proper behaviour and works nice in practice. I
think similar problems will hold similar solutions.

> Moreover one can do a push of an object, a pointer to an object, a
> reference to an object, a const reference to an object, or a const
> pointer to an object... in each case what should we do? how should we
> handle the object? how should we handle memory?

In lqt we focus on producing a module to be required in Lua. The user
is expected not to write a single line of C++, so we don't have to
expose any of this functionality outside the internal bindings system.
This is more of a problem for a binding that works both ways.

> When writing wrappers we can not suppose the object will have a proper
> copy operator, or copy constructor, because even if is never used in
> practice the code will be generated and then the compiler will raise
> an error. But, also, there are objects that maybe we don't want to be
> copied, for smart pointer for example what we really want is to
> increase and decrease the reference counter, ...

cpptoxml will tell you if you have copy constructors and such, so I
don't see what's wrong. The main goal is to let any kind of
manipulation to occur at Lua level if the automatic defaults fail for
some reason.

> The problem is even bigger when we allow to create objects from within
> the Script and then we return those objects from the script to the C++
> side. Who should handle the memory then?

The generator won't know. We assume some more or less sane default and
you are able to change that manually.
I know it's a suboptimal solution, but I fail to see how manual
bindings can make this better...

> That's why I think is quite difficult to write a GENERIC wrapper
> generator for C++ to lua, for particular libraries maybe its easy, and
> for "good"/"normal" code is also possible, but complete generic... I
> don't really think so, there is no generic policy that could cope with
> all possible classes.

I admit that a completely generic wrapper is impossible, but something
that binds automatically 50% of the libraries you throw at it would be
of some help, in my opinion.

> I will try to have a look at cpp2xml, and lqt, and see what we can do
> there. For OSG, just in case you need it, the best solution I can come
> with is using osgIntrospection to generate the wrappers (that should
> be easy, for most classes but I bet there are lots of exceptions).

It seems cpptoxml has attracted more interest than the actual bindings...