Important: Please read the Qt Code of Conduct -

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

    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?

  • Lifetime Qt Champion


    Do you have the same issue if using qint8 as enum type ?

  • No, the change from quint8 to qint8 has 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.

Log in to reply