qobject_cast<T> in shared libraries...

[The Storm]

I personally think that you should report your suggestion to the Qt guys, it will be nice to have it in Qt 4.5.

[caduel]

This (known) "issue" (or feature, if you want; probably this implementation is faster and was chosen with purpose) can be worked around by having the common base class put inside a lib that both "parties" link against. That way there will be only one such metaobject and the qobject_cast will not fail.

Still, reporting it to the trolls won't hurt.

HTH
PS: There are (some) compilers that internally use a string-compare for dynamic_cast, too.
g++, however, uses (for efficiency reasons - again) a pointer comparison of the internal rtti object. Thus, dynamic_cast may (and with g++ does) suffer from across shared library issues, too.

[seim]

Thanks for answer,

This (known) "issue" (or feature, if you want; probably this implementation is faster and was chosen with purpose) can be worked around by having the common base class put inside a lib that both "parties" link against. That way there will be only one such metaobject and the qobject_cast will not fail.

I thougth, that this common base class can be also QObject, because both sides (plugins) link against Qt libraries. Or am I wrong?

[caduel]

No. (Only if you try the rather pointless qobject_cast<Qbject*>(...) ;-)

If you do a qobject_cast<T*>(someObj) then the definition of T has to be in a common library. You must not have the header of T added in two .pro files' HEADERS-sections. Otherwise the Q_OBJECT macro will be moced and compiled multiple times. This would lead to multiple instances of the metaobject and the problem you noted.
If you put the definition of T into a lib there will be only one metaobject (the one defined by the lib) and the qobject_cast will work as expected.

HTH

[seim]

You must not have the header of T added in two .pro files' HEADERS-sections. Otherwise the Q_OBJECT macro will be moced and compiled multiple times. This would lead to multiple instances of the metaobject and the problem you noted.

Thank you, this is the key! Interface header file was included in both plugin projects and that led to 2x different static objects for "one class". Shame on me

[seim]

One more thing as a solution given by B.Poulain:

"The problem come from the declaration of the
class IObject without the macro Q_DECLARE_INTERFACE. This macro should
be used for all objects exported outside the plugin.
If you add it, everything works fine.

If you look at the declaration of Q_DECLARE_INTERFACE, it use a slightly
different approach to make qobject_cast working across library but
without being dependant of the linker."

The IObject header file has to be added in both .pro files.

Thank you all, for your posts.