[Qt-interest] Sanity check on using dynamic_cast<> with Qt

[K. Frank]

Oliver -

Thanks.

On Tue, May 11, 2010 at 8:56 AM,  <Oliver.Knoll at comit.ch> wrote:
> K. Frank wrote on Tuesday, May 11, 2010 3:39 AM:
>
>> ...
>>     [qobject_cast] doesn't require RTTI support and it works across
>> dynamic library boundaries.
>>
>> Am I correct, therefore, that qobject_cast should be more portable
>> than dynamic_cast across the platforms on which Qt runs?
>
> It is more portable in a way, yes: dynamic_cast<> requires "RTTI" (Run-Time Type Information) be enabled in the compiler, which also produces slightly larger object code. In the early days not every compiler which was supported by Qt did support RTTI properly (and there is also a slight performance overhead).
> ...

It looks like it sort of six of one, half a dozen of the other...

So, in keeping with my "learning Qt philosophy" and to stay in that
"Qt frame of mind,"
I will go with qobject_cast for the time being.

> The later requirement - the class declaration *must* contain the Q_OBJECT macro (even if it does not add signals or slots of its own)! - can't be stressed enough! Otherwise the result is "undefined" (in practise you probably get the information from the last parent object which contains the Q_OBJECT macro)! Take a careful  note of the warning in http://doc.qt.nokia.com/4.6/qobject.html#qobject_cast. ;) (1)

Yes, I do have Q_OBJECT -- my class does have a signal and slot of its
own -- so I should
be good to go here.

> ...
> Cheers, Oliver

Cheers!

K. Frank