[Interest] dynamic_cast failing

René J.V. Bertin rjvbertin at gmail.com
Sat Apr 11 21:50:53 CEST 2015


On Saturday April 11 2015 10:43:14 Thiago Macieira wrote:

> Without concrete code it's difficult to be sure, but the usual suspect in this 

Right now I'm grappling with Okular (http://quickgit.kde.org/?p=okular.git&a=tree), but I've seen the same issue occur in other "KPart" based KDE applications.

Class "D" from my original message is Okular::Part (http://quickgit.kde.org/?p=okular.git&a=blob&h=9eebdb2cd033eaec00ea88b57545721173e745f0&f=part.h&o=plain)
Class C is KPart::ReadWritePart (from kdelibs)
Class A is Okular::ViewerInterface (http://quickgit.kde.org/?p=okular.git&a=blob&h=c3de2e9bbebf7c7e12ba029150c59ccc9f097834&f=interfaces%2Fviewerinterface.h&o=plain) which appears to be a purely abstract class.

> kind of problem is the same: your virtual tables are not properly anchored in 
> shared libraries.

Can that be something that behaves differently on different OSes, or using different C++ runtimes (libstdc++ vs. libc++)?

Is it OK if the shared library is loaded dynamically (through dlopen)?

> Make sure that all classes participating in this party check all these boxes:
>  * have an export macro in the class declaration
>  * the primary virtual function is in a .cpp, NEVER inline
> 
> The primary virtual function is the first newly overriden function in the 
> parent classes' order or, if none are overridden, the first new virtual. 
> Usually, polymorphic classes have virtual destructors and destructors are 
> always overridden, so this is your best bet.

I'm going to read this a couple more time and see it gets me any further as I think it should :)

Thanks,
R.



More information about the Interest mailing list