[Development] RFC: new moc feature

Marc Mutz marc.mutz at kdab.com
Sat Dec 5 20:06:22 CET 2015


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?

What's wrong the the old and trusted

  switch (propName.front()) {
  case 's': if (propName == "scale3D") ...
  case 'r': if (propName == "rotation") ...

(and why the QByteArrayLiteral in the original code)?

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts



More information about the Development mailing list