[Kde-bindings] next parser draft

Richard Dale Richard_Dale at tipitina.demon.co.uk
Fri Jan 10 15:28:34 UTC 2003


Thanks to Germain for setting this list up - excellent idea!

On Friday 10 January 2003 11:21 am, Ashley Winters wrote:
> new features:
> command-line option for classname: -c QClass
> operators
> const
> enum constants
> qualifiers: public/private/protected/virtual/static/volatile
> default argument detection
> un-typedefing (WId becomes 'long unsigned int')
> type qualification (BackgroundMode becomes 'Qt::BackgroundMode')
> hiding internal compiler functions: /^__/
> constructor/destructor flagging
>
> There's more, probably. I've just forgotten. My 348 lines of code are
> attached.
>
> As for default arguments, I'm not going to attempt to decompile them.
> It's probably legitimate to do void foo(int = func() * func()); most
> any sort of expression is allowed, really. Instead, I just pretend
> there are really two separate functions:
>
> foo()
> foo(int)
>
> I'll probably add support for function/method pointer arguments, which
> requires a bit of effort to get right. Since I undo all the typedefs,
> they crop up in places (read: KDE).
>
> Enjoy!
Yes, just did - very interesting! It really does work well, apart from this:

private void setBackgroundModeDirect(QWidget*, 
GCC::enumeral_type=HASH(0x1e4f718))

But it seems pretty complete. Is there class heirarchy info in the 
translation-unit - can you get the parents of a class?

For languages like java, the bindings still need method arg names and doc 
comments. The best solution for me, would be to add an optional first pass to 
kalyptus analysing the translation-unit info, followed by the usual parse of 
the headers in a second parse. Any method name/type signatures found in the 
first parse analysing the translation unit would take precedence over ones 
found in the second stage when parser the headers. If a matching method 
name/type signature was found in the header parsing stage, then argument name 
and doc comment info could be added to info already found from the 
translation-unit.

Or should we have a common XML format to make it easy to combine parsed info 
of the Qt and KDE libs aquired from different sources? Eg: from 
translation-unit, from C++ headers, hand annotated stuff and from the C++ 
sources (for Qt qdoc comments). Then the translation unit dumper could output 
the parsed info in the common XML format.

-- Richard



More information about the Kde-bindings mailing list