After trying to debug unsuccessful dynamic downcasting, I eventually found that the reason was probably this: type_info :: hash_code for the type that it distinguishes does not depend on where in the called code. type_info :: name remains exactly the same. Unfortunately, I cannot reproduce the behavior in the minimal example, as it appears in a rather confusing context. Therefore, I am essentially looking for a clue to what might be causing this behavior, and therefore what direction I can take to solve this problem.
In short, if this is related, the type looks like this (EDITED):
class A {...} template < template <class> class> class B : virtual public A {...} template < template <class> class> class C : virtual public A {...} template < template <class> class> class D : public B, public C {...} template <class> class E {...}
The problem is as follows:
D<E>* d = build_d(); B<E>* b = d; A* a = d; dynamic_cast<D<E>*>(b);
Calls to type_info :: hash_code are made inside different libraries (my own). After digging, I found about the -rdynamic compiler with GCC (even if I use Clang). I am not sure if this could be due to my problem.
EDIT: I ended up finding a good clue. Unfortunately, there is no solution yet. Apparently, the problem may be related to Qt at the end.
The problem arises in the function of the slot. When a slot is triggered by a signal, downcasting dynamic_cast fails. But if I manually call the slot instead (mostly, for example), it will succeed. And if you manually call the slot, then run it on a signal, it also succeeds. There is no argument for the signal, and the contents of the slot are “neutralized” and independent of any parameter. 99.99% are sure that the problem is not due to a distribution algorithm error.
It seems that qt_static_metacall, when calling a slot, somehow loses traces of casting properties. Is the fact that the associated moc that has been precompiled may have something to do with this?