Can someone look up the history of ths class in qflags.h? That or its use in 
src/tools/moc/generator.cpp (it's used in one line)

moc uses this class to generate code for Q_PROPERTYs whose type was seen to be 
be the result of a Q_DECLARE_FLAGS. Then, instead of emitting the property 
getter/setter on the actual QFlags<E> type, it emits something based on an 
integer, such as in moc_qlibrary.cpp:

case 1: 
*reinterpret_cast<LoadHints::Int *>(_v) = _t->loadHints().toInt(); break;

case 1: 
_t->setLoadHints(QFlag(*reinterpret_cast<LoadHints::Int*>(_v))); break;

I do not understand why it is using integers here in the first place and I 
don't think this is implemented correctly either. Before I even attempt to fix 
this, I need to understand why it emits code like above. Specifically:

    Why is it using QFlag instead of LoadHints::enum_type?

The only reason I can think of is that this allows the setter function to take 
an integer instead of the QFlags type, because QFlag can be implicitly 
converted to any QFlags and to int. But I am not confident that this was the 
goal, as opposed to a side-effect.


This code is NOT matched by QMetaProperty;:read and write. Those create a 
QVariant of the actual property type (the QFlags), so the reinterpret_casts to 
Int above are type punning.

Also note this does not apply if the QFlags type was not seen to be a 
Q_DECLARE_FLAGS, such as when it is not from that class, as in 
(moc_qwindow.cpp):

case 2: *reinterpret_cast< Qt::WindowFlags*>(_v) = _t->flags(); break;
case 2: _t->setFlags(*reinterpret_cast< Qt::WindowFlags*>(_v)); break;
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Principal Engineer - Intel DCAI Platform & System Engineering

Attachment: smime.p7s
Description: S/MIME cryptographic signature

-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Reply via email to