Am 23.06.2014 um 18:06 schrieb Thiago Macieira <[email protected]>:

> Em seg 23 jun 2014, às 12:08:05, Till Oliver Knoll escreveu:
>> Am 23.06.2014 um 03:11 schrieb Thiago Macieira <[email protected]>:
>>> ... In QObject and qobject_cast's case, it's the
>>> meta object (the output of moc); for RTTI and dynamic cast, it's the
>>> typeinfo. Each must exist in a single library.
>> 
>> Not sure whether I fully understand your "[runtime info] must exist in a
>> single library" requirement here, but I always thought that the advantage
>> of using the "Qt Meta System" over the RTTI was that the former would work
>> "across library boundaries", whereas the later not (guaranteed, since
>> compiler-specific).
> 
> In all compilers that Qt supports, the requirement is the same: there is one 
> structure that must be exported from a single library. For QObject, it's the 
> meta object; for RTTI, it's the typeinfo.

Are we talking about the same thing here when referring to "across library 
boundaries"?

You say that there must be exactly one /single/ library (in numbers: one) which 
must export the relevant meta info.

In the example I gave there are at least /four/ libraries involved exporting 
(using) meta info: qtcore, foo, bar, foobar.

In my understanding I can define in each off those libraries further 
sub-classes of a given base class (QObject), run moc on each of those *.h class 
files (which /normally/ produces a moc_foo.h class file - so I don't get your 
point how you could possibly "confuse" those *.h files either - unless I never 
do "silly mistakes", off course ;)), have the moc'ed file compiled, linked and 
exported from the corresponding DLL (foo.dll, bar.dll, ...) and qobject_cast 
always gives me the correct result, no matter where called (adhering to the 
class hierarchy, off course).

So which - in your scenario - would be the SINGLE ONE DLL exporting all 
relevant Qt Meta Info?

And I /still/ think that was exactly one of the (many) selling points of using 
the Qt Meta Object over the RTTI, because the later is /not/ guaranteed to work 
"across DLLs" when it comes to dynamic casting... it even sais (said) so in the 
Qt docs, IIRC.

I think we are talking different stuff here, are we not?

Cheers,
  Oliver
_______________________________________________
Interest mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/interest

Reply via email to