[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bindings
Subject:    Re: [Kde-bindings] A sample of our subset of QtC
From:       Ashley Winters <jahqueel () yahoo ! com>
Date:       2003-01-11 19:48:27
[Download RAW message or body]


--- Richard Dale <Richard_Dale@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
_______________________________________________
Kde-bindings mailing list
Kde-bindings@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-bindings
[prev in list] [next in list] [prev in thread] [next in thread]