[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-bindings
Subject: Re: [Kde-bindings] KDE/kdebindings/generator/generators/smoke
From: Richard Dale <richard.dale () telefonica ! net>
Date: 2010-06-20 22:10:02
Message-ID: 201006202310.03175.richard.dale () telefonica ! net
[Download RAW message or body]
On Friday, June 11, 2010 12:33:27 am Arno Rehn wrote:
> SVN commit 1136866 by arnorehn:
>
> Fix this long-standing bug in SMOKE:
>
> Previously, a method call through SMOKE would always call a specific
> implementation, even though dynamic dispatch would be the correct calling
> way. The problem was to distinguish between cases where dynamic dispatch
> is the correct way of calling and cases where that specific method and
> nothing else should be called.
>
> This is now fixed in the following way: if an object is created through
> smoke (i.e. it's really an x_Foo class), then we DO NOT use dynamic
> dispatch, so calls to the parent implemenation of a method will work.
>
> However, if the object is not an x_Foo class (i.e. it was returned by some
> other method), then we use dynamic dispatch, so internal classes that are
> not wrapped by the bindings will still work (e.g. subclasses of
> KPluginFactory, KParts::Part, etc...).
>
> A virtual method call now looks like this:
>
> // virtual const QMetaObject* metaObject() const
> if (typeid(*this) == typeid(x_QObject)) {
> const QMetaObject* xret = ((const
> x_QObject*)this)->QObject::metaObject(); x[0].s_class = (void*)xret;
> } else {
> const QMetaObject* xret = ((const
> x_QObject*)this)->metaObject(); x[0].s_class = (void*)xret;
> }
>
> The overhead for the typeid() calls should be minimal. The information is
> either provided at compile time or directly retrieved from the vtable.
Is typeid() always guaranteed to work even in dynamically loaded libs? I
thought there were problems with C++ rtti for dynamically loaded libs with
things like dynamic casts, and I don't know if typeid() is one of those sort
of things. But the fix seems a very good idea apart from that - this will fix a
lot of broken behaviour I think.
-- Richard
_______________________________________________
Kde-bindings mailing list
Kde-bindings@kde.org
https://mail.kde.org/mailman/listinfo/kde-bindings
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic