[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Automatic Qt bindings updates
- From: "Mauro Iazzi" <mauro.iazzi@...>
- Date: Mon, 15 Oct 2007 11:54:13 +0200
gccxml is a good thing. Parsing XML is a breeze and it gives the most
exact informations on the code that you can extract from the code
(however it means inferring the design of the interface from
implementation, so you can only guess the use: it is prone to errors
in uncommon design patterns).
Stressing again: all the information that can be taken from code only
is there. This unfortunately does not tell you (e.g.) what an int*
argument wants to take (is it passing by ref or an array). Even a char
* argument is ambiguous, because you don't know whether it should be
null terminated or the lenght is written in some other place.
These are fundamental problems and cannot be overcome looking at the
source only. Thus you'll need to look at the docs (either manually or
parsing them if a system is in place).
However, if the binded code has a coherent design (as Qt) this
approach can be very effective.
Template things are almost imp[ossible to do by now. A lot of problems
arise when you take into account templates, because concepts are not
implemented in C++ yet. Even if there were, it wouldn't be sure that
bindings were feasible at all.
Templates in C++ are strictly bound to static typing of the language.
Arguments must know every bit of the type they represent at compile
time so you cannot make a generic type which moves the possibility for
deciding at runtime (in general, but in particular it appies to Lua
bindings). Everything the template uses of the argument cannot be
changed at runtime. Unless you can exactly tell what of the argument
type is used by the template and manage to implement it generically.
An example shows better:
template <class T>
class A {
public:
T::ret_type foo(T t) { return t.bar(); }
};
You'd like to instantiate it with something like
class LuaT {
public:
typedef LuaVariant ret_type;
ret_type bar() { /* callback here */ }
};
In this case if you don't know what functions you are required to
provide you cannot guess.
Notice that this applies also to the LuaVariant type, which is an
implicit argument of the template for which you cannot say if sum or
equality (for example) operators must be provided.
If there were concepts, some syntax would describe what is actually
needed by the template, so you could (with some difficulty, probably)
try to construct such a generic type automatically. C++0x will sport
concepts, but I don't know to which extent.
Single instances of templates can be used as classes without problems.
I know nothing of CGAL in particular.
mauro
On 15/10/2007, Wesley Smith <wesley.hoke@gmail.com> wrote:
> I was looking at gccxml for doing auto bindings. The VTK toolkit has
> a similar scheme for gccxml->SWIG generation. I'm curious as to how
> flexible this method is and how it can be used to handle rather
> complicated libraries that have alot of template interdependencies
> like CGAL.
>
> thanks,
> wes
>