[Kde-bindings] A sample of our subset of QtC

[Ashley Winters]

--- Richard Dale <Richard_Dale at tipitina.demon.co.uk> wrote:
> On Friday 10 January 2003 8:20 pm, Adam Treat wrote:
> I don't convert any of the methods
> with HANDLE 
> and 'Display *' types because they're X11 specific, and I'm only
> interested 
> in a cross platform api (in java anyway).

Makes sense. I wonder if you could... arrange for the ISXXX OS macros
to all be undefined when you drive the headers through -fdump-t-u, so
no platform-specific functions are included.

> 'QApplication *' is a C++ type, and I wouldn't have thought you could
> bracket 
> it within an extern "C" {.. } block as you've done below.

Well, extern "C" only defines the linkage. It's hardly a legal C
header, which would be a requirement for a real version of QtC. Without
C headers to go along with the library, it's only half functional.

Also, it's rather unpleasant to have the possibility of function "ids"
changing between versions. If you're gonna tack an effectively random
number on the end of every function, why not go all the way like smoke
does? f1, f2, ..., f4897.

I'd propose using a standard name-mangling scheme for the arguments.

QApplication(const char **, int)
QApplication_cCPP_i  (char CONST POINTER POINTER, int)

It would be possible to document a mapping from "mangled" names to
"easy" names that way. qtc_QApplication() would always call
QApplication_cCPP_i or something

Ashley Winters

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com