[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Lua binding compare-and-contrast
- From: David Wolfe <evadeflow@...>
- Date: Sat, 18 Dec 2010 16:38:25 -0500
I have read that GCC is able to output XML out of C[++] code too.
Out of curiosity, why having chosen Doxygen instead of that? Simpler
to parse?
I think you are referring to gcc-xml [1]. A similar approach is used
in Lqt bindings with the custom-written cpptoxml [2] parser.
IMO the Doxygen output is better suited for binding - undocumented
functions will simply not be bound. However, gccxml and cpptoxml will
pick up every method it finds in header files :)
gcc-xml seems like the obvious choice to me. Doxygen comments have to be
added to headers manually, which is a PITA. And they're a maintainance
burden just like regular comments. How many times have we all seen
something like this:
// Bump gain by a factor of 1.5 to compensate for AD65Q freq
gain_ *= 1.78;
Any system that relies on comments being up-to-date seems dubious.
gcc-xml works on the raw C++ headers, so the output XML is automatically
up-to-date w.r.t. the source, and there's no opportunity to introduce
errors.
The Python-Ogre project (http://www.pythonogre.com/) uses the python
bindings for gcc-xml (pygccxml) to programmatically generate C++ binding
code that, ironically enough, targets Boost-Python. It may seem odd to
use a code generator to write code for a tool whose chief claim to fame
is that it doesn't require a separate code generation step, but it's a
very pragmatic solution in practice that eliminates a lot of
duplication. (I've often wished a similar tool existed for luabind.)
You can say things to the py++ code generator like: "Give me a reference
to all classes in the namespace 'util' whose name matches the pattern
'Vec*'. Okay, for all those classes, emit the following binding code."
So you generate the bindings for Vec2f, Vec2d, Vec3f, Vec3d, Vec4f,
Vec4d, etc with a single block of python script, instead of writing the
bindings in C++ by hand and cutting/pasting for all the different
variants.
Of course, you wouldn't need to target Boost-Python on the back-end.
Using pygccxml by itself, you can emit whatever binding code you want.
If a lua port of pygccxml existed, you could even do it all in Lua.
That, to me, would be the 'holy grail'...