[Kde-bindings] KDE/kdebindings/generator/generators/smoke

[Richard Dale]

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