[Kde-bindings] kalyptus can now generate a SmokeKDE library

[Ashley Winters]

--- Richard Dale <Richard_Dale at tipitina.demon.co.uk> wrote:
> On Wednesday 17 September 2003 15:28, Germain Garand wrote:
> > Le Mardi 16 Septembre 2003 16:16, Richard Dale a écrit :
> > > I've just checked in some changes to the kalyptus parser and
> Smoke code
> > > generation, so it parses the current kdelibs ok - it just does
> the whole
> > > of the Qt/KDE libs and puts the whole lot in a single
> libsmokekde.so. It
> > > compiles, but I haven't tried it yet.
> >
> > Yum! I hadn't any luck in linking it yet, but it does compile fine!
> > That's a wonderful playground you are opening there :-)
> Indeed, if I run rbqtapi heroic amounts of stuff appears.. I think
> getting rid 
> of useless classes is quite important to get the lib size down:
> 
> 15512 -rwxrwxr-x    1 duke     15862346 Sep 17 12:36
> libsmokekde.so.1.2.1

Whoa! That is big. I'm impressed, though.

> Will the new vtable scheme in Smoke v2 cut down the code bloat caused
> by all 
> the inherited virtual methods being copied into the descendant
> classes for 
> the callbacks?

That question is still open. I loathe the current virtual function
bloat created by trivial subclasses overriding 40+ virtual methods. The
question is to what degree we're willing to go to abolish this
nuisance.

Well... how about we go whole hog? Not quite to the binary level, but
still deep magic. :)

I'm going to assume that for most/all Qt platforms, this would work:

Given a class X defined in the target library, declare a class Xp with
the same virtual methods in the same order, but without any member
variables or other member functions, and swap their virtual tables
thusly:

*(void**)(X*)obj = *(void**)(Xp*)vtbl;

In the case of multiple inheritance, go ahead and follow the same
inheritance tree in the Xp classes, but multiple vtable assignments are
required.

For each class multiply-inherited, do:
*(void**)(X*)obj = *(void**)(Xp*)vtbl;
*(void**)(Y*)obj = *(void**)(Yp*)vtbl;
*(void**)(Z*)obj = *(void**)(Zp*)vtbl;

I've tested these vtbl hacks on Linux and Windows, and the same code
works on both. I'm going to whip up a test program and see how many of
the sourceforge compile farm servers will let it pass. :)

It is not possible to have the Xp classes contain any member variables,
since I have NO CONTROL over the destructor sequencing. The virtual
destructor for the Xp class must do nothing whatsoever so that it can
manually call the regular X destructor.

I have code which does this, but it's a bit ugly.

What does this mean?

Any class which inherits from QWidget but doesn't ADD any new virtual
methods could use the same Xp class as QWidget. As you can imagine,
this would significantly reduce the size of the smoke library, since
only classes which add a virtual method would need to have all its
virtual methods overridden.

The Xp classes would pass along virtual function calls to a
function-pointer in a table supplied by the language binding. If QFoo
inherits QWidget and overrides mousePressEvent(), it would use the same
Xp class as QWidget, but the function-pointer table would know to call
QFoo::mousePressEvent.

Does this make sense, or is some example-code required? It's a bit much
even for me. However, it can be done in a semi-portable way.

Ashley Winters


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com