I personally think that you should report your suggestion to the Qt guys, it will be nice to have it in Qt 4.5.![]()
I personally think that you should report your suggestion to the Qt guys, it will be nice to have it in Qt 4.5.![]()
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.
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
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.
![]()
Bookmarks