[Development] Storing is-a QObject fact with metatypes

Olivier Goffart olivier at woboq.com
Fri Dec 2 18:05:41 CET 2011


On Friday 02 December 2011 10:57:07 Stephen Kelly wrote:
> Hi,
> 
> There is a lot of work going into the Qt metatype system at the moment, and
> I would like to put my oar in too.
> 
> I would like to store the fact of whether a type inherits QObject with the
> qmetatype information.
> 
> This would allow things like this:
> 
> QVariant v = QVariant::fromValue(new QAction); // Any QObject subclass
> 
> // Somewhere else:
> 
> if (v.canConvert<QObject*>() {
>     QObject *obj = v.value<QObject*>();
>     // ...
> }
> 
> // Now use the properties on obj, or connect to its signals and slots.
> 
> 
> Implementing this just needs a SFINAE template, and isn't unduly complex.
> 
> The problem is that it introduces a slight source incompatibility. The
> SFINAE template requires that the full type be declared instead of just
> forward declared. That is, things like this, which are possible with Qt4
> would not work anymore:
> 
> class MyClass;
> Q_DECLARE_METATYPE(MyClass*)
> 
> void foo(MyClass *aFoo)
> {
>   QVariant v = QVariant::fromValue(aFoo);
> }
> 
> void choo(const QVariant &aChoo)
> {
>   MyClass *c = aChoo.value<MyClass*>();
> }
> 
> // MyClass still just forward declared!
> 
> Similarly, qRegisterMetaType<MyClass*>() would require MyClass to be fully
> defined, whereas currently it does not. Being able to use these APIs when
> the tpr is not fully defined makes sense inside QtCore where types in QtGui
> need to be forward declared for example, but I don't think there's a great
> need to allow forward declared types outside of that case.devl
> 
> To add a migration path I would add QVariant::fromForwardDeclared<T>() and
> qRegisterForwardDeclaredMetaType<T*>() (along with helper template methods)
> which don't use the SFINAE and therefore behave in Qt4 compatibility and
> Q_FORWARD_DECLARE_METATYPE() macro which would not use template methods
> which rely on SFINAE.
> 
> It is very uncommon to use forward declared type like is currently allowed,
> so this would be optimizing for the more common case. I think this would be
> beneficial to QML related APIs.
> 
> What do you think of the proposed change?

How much does it break to require type to be defined?
It is probably ok to force the type to be defined.





More information about the Development mailing list