Hi Thiago,
Do I understand it correctly that the approach with constexpr functions will
allow us to solve the problems with moc (point 2 from the first e-mail
of the thread)?
If yes, then I think we should try to implement that approach, and do not
introduce a separate class for 64-bit QFlags.
> 1) BC of QFlags in existing structures and parameters
> I want to avoid a silly mistake in someone adding an extra enumerator and
> suddenly changing the size of the underlying enum from 4 to 8 bytes.
I understand this argument, but I do not think that it's critical.
> We may not consider this a problem. There is obviously no safety belt for non-
> QFlags enums.
That's exactly what I have in mind. The plain enums are usually also used
in the APIs, so if the users care about BC, they will have issues anyway.
And if they don't, they can surely live with QFlags silently changing its
size.
> This means developers *must*
> add an explicit underlying type to the enumeration in order to use it as 64-
> bit if you care for cross-platform compatibility.
+1 for that! That's one of the things that we pay attention to during API
review in Qt, so hopefully all new Qt APIs will either use `enum class`,
or explicitly define an underlying type.
Best regards,
Ivan
------------------------------
Ivan Solovev
Senior Software Engineer
The Qt Company GmbH
Erich-Thilo-Str. 10
12489 Berlin, Germany
ivan.solo...@qt.io
www.qt.io
Geschäftsführer: Mika Pälsi,
Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht
Charlottenburg, HRB 144331 B
________________________________________
From: Development <development-boun...@qt-project.org> on behalf of Thiago
Macieira <thiago.macie...@intel.com>
Sent: Thursday, August 8, 2024 8:34 PM
To: development@qt-project.org
Subject: Re: [Development] 64-bit QFlags support
On Thursday 8 August 2024 11:22:39 GMT-7 Thiago Macieira wrote:
> My solution is to have moc parse a new declaration Q_DECLARE_FLAGS64, which
> indicates the flag is 64-bit, and then generate different data. I have not
> implemented Q_FLAGS64 or Q_ENUM64 yet.
An alternative solution I am looking into right now is to move the integer
array generation to C++ constexpr functions, like we did for the string array.
In those functions, we can know that the enumeration is 64-bit wide and then
generate the extra fields without having to have moc understand that they are
64-bit. In theory this will work, but in practice we need to test the multiple
compilers extensively to know if we won't overflow limitations in constexpr-
time execution or just plain compiler bugs (MSVC fails with [1] for example
and generates bad code). The moc output would look something like:
static constexpr std::array qt_meta_data_CLASSUserClassENDCLASS =
QtMocHelpers::uintData()
.addClassInfo(1, 3)
.addClassInfo(4, 5)
.addMethod(6, 2, 0x06, { QMetaType::Void, 0x80000000 | 17, 8 })
.addMethod(7, 2, 0x06, { QMetaType::Void, 0x80000000 | 9, 8 })
.addMethod(8, 2, 0x0a, { QMetaType::Void })
.addEnum(10, 10, 0x00, { 11, 12 }, { UserClass::V0, UserClass::V1 })
.addEnum(13, 14, 0x01, { 15, 16 }, { UserClass::F0, UserClass::F1 })
.generate(/* revision */ 12, /* flags */ 0);
There's no guarantee this will work, and especially that it will for C++17,
though I wouldn't mind declaring you must use C++20 to access 64-bit
enumerators.
If this works, we get the best of both worlds: all 64-bit enumerations and
flags automatically get their high part stored without impacting the existing
32-bit ones, and moc doesn't need to know that they are 64-bit.
Long-term, we should generate the char, integer and metatype arrays in a
single call, so it can be used with C++ reflection. I have a hard time figuring
out how that can be accomplished even without it.
[1] https://codereview.qt-project.org/c/qt/qtbase/+/537384
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
