Hello Richard, CC: gents, Beside object bus, how do you deal with allocation of Qt/Kde object ? First I'd like to share you my progress on my QT4 Perl binding. Due to personal issues, I recently didn't pay much time on coding...

<br>The typemap system is almost finished. You can check here (<a href="http://dongxu.googlecode.com/svn/trunk/PerlQT/script/create_typemap.pl">http://dongxu.googlecode.com/svn/trunk/PerlQT/script/create_typemap.pl</a>)<br>

The typemap, as you know in perl, is the repos for type marshalling between perl and c++ plants. While the old typemap mechanism introduced by ExtUtil.pm is somewhat out of date, it has no knowledge about relationship between relevant types. Say, for instance, QString and QString *. Typemap simply treats them as un-relevant ones.

What I did in tha script is a knowledge study and relationship analyse system. For above example, in case it knows QString is a QObject (obviously from qstring.h), it automatically knows how to marshall QString *, QString &, const QString, const QString * and QString const *. Furtherly QList<QString *> is possible. It goes thru different aspects to find type relationship ( class declaration, inheritance tree, namespace path, pre-defined typemaps ).

<br>It is powerful enough to bridge native Qt type with KDE type, custom type.<br><br>While the bad situation I am facing is GC system. Perl uses simple reference, while ruby makes use of mark and sleep way. On the another hand, generally, various cases may mess GC:

<br>1) GC in Qt itself: Qt maintains its internal object reference status;<br>2) non-new method which exports an internal address,which will have the same lifecycle of exporter;<br>3) non-new method which returns a new heap address, which transfers the ownership of that pointer to caller;

4) non-new method which accepts a pointer and takes the ownership of that pointer; Either case will leak the vm unless treating it carefully. I'd like to hear your words on this question.  PS: boost python binding page also discussed similar issues. Go and take a look.

<br><br>cheers,<br>-dongxu<br><br><div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>Message: 2<br>Date: Tue, 17 Jul 2007 13:19:02 +0100

<br>From: Richard Dale <<a href="mailto:rdale@foton.es">rdale@foton.es</a>><br>Subject: Re: [Kde-bindings] Splitting up the SMOKE library<br>To: KDE bindings for other programming languages<br>        <<a href="mailto:kde-bindings@kde.org">

kde-bindings@kde.org</a>><br>Message-ID: <<a href="mailto:200707171319.02329.rdale@foton.es">200707171319.02329.rdale@foton.es</a>><br>Content-Type: text/plain;  charset="iso-8859-1"<br><br>On Tuesday 17 July 2007, Ashley Winters wrote:

<br>> --- Thomas Moenicke <<a href="mailto:tm@php-qt.org">tm@php-qt.org</a>> wrote:<br>> > The kalyptus generator should generate the qt_Smoke instance in<br>> > smokedata.cpp only for the Qt smoke, for KDE smoke it should have

<br>> > a kde_Smoke instance which has a pointer to qt_Smoke. In case the<br>> > inline methods of kde_Smoke don't find the index they can ask the<br>> > qt_Smoke before it returns 0.<br>> > Thus we can create a hierarchy of dependencies and don't need to

<br>> > touch too much in the implementations:<br>> ><br>> > + qt_Smoke<br>> > +--+ qwt_Smoke<br>> > +--+ kde_Smoke<br>> >     +--+ whatever_in_kde_Smoke<br>> > +--+ qscintilla_Smoke

<br>> ><br>> > I think this way would follow the design currently implemented in the<br>> ><br>> > bindings, but i would like to hear the opinion of Ashley though.<br>><br>> Yeah, a single-inheritance hierarchy should work. You first search your

<br>> "local" copy of smoke, and if something's missing you forward the<br>> search to your parent.<br>><br>> I went through my old code to try and refresh my memory of the issues<br>> with combining Smoke libraries. PerlQt had a class already written for

<br>> merging Smoke instances, but it was never made to work.<br>><br>> and the SmokePerl class declaration (with comments) here:<br>> <a href="http://search.cpan.org/src/GGARAND/PerlQt-3.008/PerlQt/smokeperl.h">

http://search.cpan.org/src/GGARAND/PerlQt-3.008/PerlQt/smokeperl.h</a><br>><br>> And the implementation via the SmokePerlQt class here:<br>> <a href="http://search.cpan.org/src/GGARAND/PerlQt-3.008/PerlQt/smokeperl.cpp">

http://search.cpan.org/src/GGARAND/PerlQt-3.008/PerlQt/smokeperl.cpp</a><br>><br>> It seems I even implemented a Smoke API for loading multiple libraries<br>> from within Perl:<br>><br>> <a href="http://perlqt.cvs.sourceforge.net/*checkout*/perlqt/PerlQt-3/PerlQt/smokepe">

http://perlqt.cvs.sourceforge.net/*checkout*/perlqt/PerlQt-3/PerlQt/smokepe</a><br>>rl.cpp?revision=1.1.2.16&pathrev=dev-3_0_0<br>><br>> Apparently I went homeless before finishing that. It's too bad, cause

<br>> that was some good stuff. I can hardly remember how it works, now. :)<br>><br>> From browsing through the code, it looks like smoke-qt and smoke-kde<br>> didn't directly reference or inherit each other. They each filled in

<br>> the AUTOLOAD (method_missing for Perl) for the classes which they<br>> respectively defined, and let the language method dispatcher handle<br>> finding which class the method was defined in. Each class knew which

<br>> Smoke* object it came from, and each object knew which Smoke* it<br>> belonged to.<br>OK, I've had a read, and in fact some of that code is still in qtruby, and<br>then ported to qyoto. But I didn't understand the 'hasFire()' method quite -

<br>why would only certain classes know which Smoke instance they belonged to?<br><br>class SmokeClass {<br>...<br>    bool hasFire() const { return !(flags() & Smoke::cf_undefined); }<br><br>I think we just need a hash table called GlobalSmokeClasses

<br>of 'full_class_name => smoke instance' and load into it each time a new smoke<br>module is loaded.<br><br>When we look up a method for an instance we always provide the classname of<br>the instance, and each instance already has which Smoke instance its class

<br>belongs to inside the 'smoke_perlobject' struct. So as long as we have the<br>strings which give the names of superclasses that are not in the current<br>Smoke instance, we can look them up the smoke instances of the parent classes

<br>when finding a method via the GlobalSmokeClasses hash. Then the classFn for a<br>particular method won't always be in the same Smoke instance that the<br>ruby/perl/csharp/php instance belongs to as now. But the code to call a

<br>method would be much the same.<br><br>I don't think a particular Smoke module has to know which parent modules it<br>has, only the individual classes need to know what their parent class names<br>are as strings.<br>

<br>Virtual method callbacks will need to have methods that are not in the current<br>smoke module, but as far as I can see that should work ok at runtime, and it<br>just makes the code generation harder.<br><br>-- Richard

<br></blockquote></div><br><br clear="all"><br>-- <br><a href="http://search.cpan.org/~dongxu">http://search.cpan.org/~dongxu</a>