C++ Enum class exposed to QML is read with more bits than defined in Qt 5.15 as opposed to 5.12
-
I ran in some strange looking issue in our code today. We call a C++ class member from within QML, which returns an
enum class SomeEnumeration : quint8 {MEMBER_0=0,MEMBER_1=1,MEMBER_2=2,MEMBER_3=3,MEMBER_4=4,MEMBER_5=5};.In Qt 5.12.7 the value displayed in a label for that enum is a value between 0 and 5.
If I build the very same code with Qt 5.15.2, I get strange readings of 32512 to 32517
From that bit pattern it was a rough guess then that qml might not take into account the underlying type of an enum but instead interprets it as being a signed 16 bit value. (0x7F00 to 0x7F05). It seems to simply ignore the length.
This is very strange, given the fact that it doesn't do that for Qt 5.12.7.
When I cange my underlying enum type to be a 16 bit long type, the QML engine reads the correct value.
The only bug that I came over looking for the behaviour which might be related in some way was https://bugreports.qt.io/browse/QTBUG-71947
However, the issue there seems to be not about the length of 8 or 16 bits not being respected.
Any ideas how to not being forced to change all my 8 bit enums to 16 bit ones?
-
Hi,
Do you have the same issue if using qint8 as enum type ?
-
No, the change from
quint8toqint8has no effect.However, I could invesigate a bit more, but only to get more confused.
The misbehaviour happens when I compile the project with MSVC2019. When I change the enum to be represented by a 16 bit type, it translates to the correct values.
When I compile the Project using MSVC2017 and Qt 5.12.7, the enum also translates correctly.
When I compile the project using MinGW, the enum, even when
quint8-based gets also translated correctly.I then tried to reproduce the behaviour by assembling a minimal example. The project where the situation happens is a huge subdir project consisting of numerous dlls.
In the minimal example I built exactly the same mechanisms into a very smallproject consisting of only one class and one qml page. The surprising thing is: I cannot reproduce the misbehaviour in that setup, neither using MSVC2019 nor MinGW.
After that analysis, I tend to judge the microsoft compiler to be the root cause of the issue. Even when it is able to build a correctly working minimal project, in the real project only MSVC2019 is causing the issue.
Therefore I will set the topic to solved, because it hardly is a framework bug, but more of a compiler issue that shows up under certain circumstances.
