[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