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

[Richard Dale]

On Thursday 18 September 2003 06:20, Ashley Winters wrote:
> --- 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.
Actually as Germain says, it wasn't stripped so that's not too bad at 10 Mb. I 
think we might save another 3 Mb with your vtable stuff, so we might end up 
with about 7 meg. I'm still not sure what's actually in there, and whether 
there is anything major missing.
> > 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;
Omigod!! love this cast - like an alien smiley..
> 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.
Please put it in a 'black box' and hide it from us! I not sure if I did quite 
follow the above.. But even if the vtable hack can't be made to work the 
current scheme would still be 'good enough' I think.

-- Richard