[Interest] QPlugin and RTTI

Thiago Macieira thiago.macieira at intel.com
Mon Jun 23 19:24:24 CEST 2014


Em seg 23 jun 2014, às 19:13:41, Till Oliver Knoll escreveu:
> Am 23.06.2014 um 18:06 schrieb Thiago Macieira <thiago.macieira at intel.com>:
> > Em seg 23 jun 2014, às 12:08:05, Till Oliver Knoll escreveu:
> >> Am 23.06.2014 um 03:11 schrieb Thiago Macieira 
<thiago.macieira at intel.com>:
> >>> ... 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"?

I believe so.

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

Yup.

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

But each class is exported from exactly one library. QObject's meta object and 
RTTI are exported from QtCore, for example. All other modules import them from 
QtCore and never define them themselves.

> 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).

The silly mistake is to name the same header in the HEADERS of more than one 
.pro file. You wouldn't list qobject.h in your project, would you?

As long as it appears in exactly one .pro file, moc will be run in that one 
project only, thus generating the metaobject for one library only. What's 
more, since the key virtual method is in the Q_OBJECT macro, this will also 
cause the RTTI to be exported from that one library only.

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

See above. The important thing is that each class is exported from one 
library, not that one library exports all classes.

> 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?

No, we're not.

The requirement is the same, but it's easier to accomplish it with Qt.

The other selling point is that qobject_cast is cheaper than dynamic_cast.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center




More information about the Interest mailing list