On Montag, 5. August 2013 22:32:48 CEST, Jan Kundrát wrote:
On Monday, 5 August 2013 19:54:05 CEST, Thomas Lübking wrote:
Did i miss this?
Where's mentioned "does not work" (reason is perhaps lacking
Q_OBJECT macro?)
From pali-gsoc-merge:src/Common/PluginLoader.cpp:
// NOTE: qobject_cast not working when trojita is compiled as shared
library, dynamic_cast working fine
Ok, i'll open bets.
----------
Pali, did you figure this trying on the NullPlugins?
----------
On a general note and particular on this case (which i missed because after
understanding it's just for development testing i rather skipped them):
Placing "O_OBJECT" into a source file (*.cpp) does *NOT* work, the MOC does not
(easily - and I don't see that in CMakeLists.txt and NO: just write a header ;-) proceed
them, thus there's no MetaObject processing and thus there's no qobject_cast'ing to that
particular type.
Signals and slots of the base class will of course continue to work, but it's
not possible to add new ones or shadow the present.
dynamic_cast might actually work on gcc, but that's due to some gcc magic and
particular linker calls on symbol exports - it's absolutely not reliable.
In general dynamic_casting across libraries does *not* work - if you want to do
this (outside Qt happyland), you add some nice hints (eg. a type id) on the
actual type and then just static_cast them according to the type (and then you
can cast down to determine the patch - or you just move to Qt happyland =)
To hook onto that:
iirc you required Trojitá -fPIC for kontact inclusion: was there a particular
reason (from kontact side) or just because (you?) tuned up GCC parameters until
dynamic_cast'ing worked in order to make trojitá a shared library.
Cheers,
Thomas
