[Development] RFC: new moc feature

Sean Harmer sean.harmer at kdab.com
Sat Dec 5 20:20:27 CET 2015


Hi Marc,

On 05/12/2015 19:06, Marc Mutz wrote:
> On Saturday 05 December 2015 13:00:44 Sean Harmer wrote:
>> So given the above example we'd be able to have something like this
>> (name of macro pending):
>>
>>       if (e->type() == NodeUpdated) {
>>           const QScenePropertyChangePtr &propertyChange =
>> qSharedPointerCast<QScenePropertyChange>(e);
>>           switch (propertyChange->propertyNameStringId()) {
>>           case qStrId("scale3D"):
>>               m_scale = propertyChange->value().value<QVector3D>();
>>               updateMatrix();
>>               break;
>>           case qStrId("rotation"):
>>               m_rotation = propertyChange->value().value<QQuaternion>();
>>               updateMatrix();
>>               break;
>>           case qStrId("translation"):
>>               m_translation = propertyChange->value().value<QVector3D>();
>>               updateMatrix();
>>               break;
>>           case qStrId("enabled"):
>>               m_enabled = propertyChange->value().toBool();
>>               break;
>>            default:
>>               qWarning() << "Unknown property update";
>>           }
>>       }
>>
>> Where the qStrId macro expands to nothing and the preprocess tool
>> replaces its contents with the hashed value. No idea if all of our
>> supported compilers allow hooking in custom preprocessors or not.
> How do you handle the invariable hash collisions?

Not sure yet. Still thinking this through.

The chances of a collision within the scope of a comparison such as this 
is pretty small (of course dependent upon the quality of the hash 
function). If used within a hash the compiler would complain about 
duplicated case labels.

If the preprocess tool maintains a catalogue of entries in the hash it 
could also warn about collisions to allow the user opportunity to alter 
the names being used.

> What's wrong the the old and trusted
>
>    switch (propName.front()) {
>    case 's': if (propName == "scale3D") ...
>    case 'r': if (propName == "rotation") ...

Indeed, this is something we could adopt now with little effort. I was 
just wondering if we could get it down to the theoretical ideal of a 
single integer comparison mapped into the finite set of strings in use. 
Seems not, without some non-neglible effort.

> (and why the QByteArrayLiteral in the original code)?

Simple oversight. Will fix.

Cheers,

Sean

-- 
Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts




More information about the Development mailing list