[Development] QMetaTypeId and QMetaTypeId2

BRM bm_witness at yahoo.com
Thu Feb 9 16:41:55 CET 2012


> From: Olivier Goffart <olivier at woboq.com>
> On Thursday 09 February 2012 10:42:07 Thiago Macieira wrote:
>>  On Thursday, 9 de February de 2012 10.07.16, Jedrzej Nowacki wrote:
>>  > Hi,
>>  > 
>>  >   Does anybody know why we have separation between QMetaTypeId and
>>  > 
>>  > QMetaTypeId2 classes?
>> 
>>  Because the original QMetaTypeId that existed in Qt 4.0 lacked one 
> important
>>  feature, which Harald fixed in 4.2 or 4.3.
>> 
>>  Before harryF's changes, the Q_DECLARE_METATYPE macro did not save the 
> name,
>>  so you had to include the type's name in the registration function:
>> 
>>      qRegisterMetaType<MyType>("MyType");
>> 
>>  This was necessary because the type's name cannot be easily gleaned 
> from the
>>  template parameter (I have a patch for that though, see
>>  https://codereview.qt- project.org/#change,670 ).
> 
> It was before my time, but I think it is totallty unrelated to that, since 
> Q_DECLARE_METATYPE already registered the name in Qt 4.0 and that QMetaTypeId2 
> is only used for builtin types.
> 
> I beleive it has been added so adding builting type do not conflicts with 
> Q_DECLARE_METATYPE of the same type.
> 
> Indeed, in Qt 4.1, the list of supported metatype was quite small
> http://doc.qt.nokia.com/4.1/qmetatype.html#Type-enum
> But in Qt 4.2, where QMetaTypeId2 was added, that list has gained a lot of 
> types.
> Without QMetaTypeId2, customer code that would have done 
> Q_DECLARE_METATYPE(QStringList) yould break

I think this should be handled such that it won't break such that:

1. It logs that it has already been registered, and preferably where the extraneous registrations are coming from.
2. Any extraneous registrations are dropped (not processed aside from #1).


#1 is to help people track down registrations they don't need - or at least block them out so that they only occur with
Qt versions that still need them (if they need the interoperability).


> From: André Somers <andre at familiesomers.nl>
>Op 9-2-2012 12:39, Stephen Kelly schreef: 
> 
>>> Can I merge QMetaTypeId and QMetaTypeId2?
>> 
>>I always thought they were split so that Qt could add new built-in metatypes without breaking user code.
>> 
>>Eg, if you merge them, any user code doing:
>> 
>>Q_DECLARE_METATYPE(QModelIndex)
>> 
>>will no longer compile until that line is removed (It is a built-in metatype now).
>> 
>>
> Not hindered by any knowledge of the internals of these classes:
>Would it be possible to make such a statement a no-op then if the
> type is already registered?
>


The effect should be a no-op with the possible addition of a log message (e.g. qDebug()) if it is already there so that people can track down the extraneous cases.

That said, I'd like to see at least QAbstractSocket::SocketError registered as well. As it is, I typically have to register it before I can throw it through signals across thread boundaries.
I'd suggest that any type - especially enums and standard types - that is in a signal/slot in the Qt API should be registered by Qt so that a signal can be used with it across thread boundaries.

$0.02

Ben




More information about the Development mailing list