Re: [Development] C++20 structural types (was: C++20 @ Qt)
On Saturday, 5 November 2022 12:21:29 PDT Alexandru Croitor via Development wrote: > and FEATURE_systemsemaphore will be disabled on integrity due to its > condition in configure.cmake as shown below. > > CONDITION ( NOT INTEGRITY AND NOT VXWORKS AND NOT rtems ) AND ( ANDROID OR > WIN32 OR TEST_sysv_shm OR TEST_posix_shm ) Thanks, it was that condition the problem. The build at https://testresults.qt.io/coin/integration/qt/qtbase/tasks/1679390069 appears to have passed the INTEGRITY build phase. All builds except for two Windows were "Done" and I know Windows works. The CI failed on running the test now. Looks like I enabled tst_QSharedMemory with no backends on QNX (because of Id8d5e3999fe94b03acc1fffd171c22d2e8752ffb). I've changed it so that at least one backend is required on Linux, FreeBSD, Windows and Darwin systems, but made it optional for everyone else. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] C++20 structural types (was: C++20 @ Qt)
Hi, The feature is marked in configure.cmake as PRIVATE only. Try explicitly including one or both of #include #include Note that in src/corelib/ipc/qsystemsemaphore_p.h there is #if QT_CONFIG(systemsemaphore) #include "qcoreapplication.h" #include "qtipccommon_p.h" #include "private/qtcore-config_p.h" and FEATURE_systemsemaphore will be disabled on integrity due to its condition in configure.cmake as shown below. CONDITION ( NOT INTEGRITY AND NOT VXWORKS AND NOT rtems ) AND ( ANDROID OR WIN32 OR TEST_sysv_shm OR TEST_posix_shm ) From: Development on behalf of Thiago Macieira Sent: Saturday, November 5, 2022 6:18 PM To: development@qt-project.org Subject: Re: [Development] C++20 structural types (was: C++20 @ Qt) On Saturday, 5 November 2022 10:08:55 PDT Allan Sandfeld Jensen wrote: > Sure. If we can, make it a stand in for std::float16_t until we can rely on > that. https://codereview.qt-project.org/c/qt/qtbase/+/305792 https://codereview.qt-project.org/c/qt/qtbase/+/441813 https://codereview.qt-project.org/c/qt/qtbase/+/441814 I have some work for int128 and float128 too, but those are less tested. I am going to reserve the metatypes for them, though. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] C++20 structural types (was: C++20 @ Qt)
On Saturday, 5 November 2022 10:08:55 PDT Allan Sandfeld Jensen wrote: > Sure. If we can, make it a stand in for std::float16_t until we can rely on > that. https://codereview.qt-project.org/c/qt/qtbase/+/305792 https://codereview.qt-project.org/c/qt/qtbase/+/441813 https://codereview.qt-project.org/c/qt/qtbase/+/441814 I have some work for int128 and float128 too, but those are less tested. I am going to reserve the metatypes for them, though. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] C++20 structural types (was: C++20 @ Qt)
On Samstag, 5. November 2022 16:56:27 CET Thiago Macieira wrote: > On Saturday, 5 November 2022 01:16:36 PDT Marc Mutz via Development wrote: > > Done. Also for qfloat16. > > qfloat16 needs some TLC to adapt to P1467. I have the patches for that and > have tested that they work in a processor emulator[1]. Is that acceptable? > > [1] > https://www.intel.com/content/www/us/en/developer/articles/tool/software-de > velopment-emulator.html Sure. If we can, make it a stand in for std::float16_t until we can rely on that. Best regards Allan ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] C++20 structural types (was: C++20 @ Qt)
On Saturday, 5 November 2022 01:16:36 PDT Marc Mutz via Development wrote: > Done. Also for qfloat16. qfloat16 needs some TLC to adapt to P1467. I have the patches for that and have tested that they work in a processor emulator[1]. Is that acceptable? [1] https://www.intel.com/content/www/us/en/developer/articles/tool/software-development-emulator.html -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] C++20 structural types (was: C++20 @ Qt)
On 05.11.22 08:24, Marc Mutz via Development wrote:
> There's alsohttps://bugreports.qt.io/browse/QTBUG-94266
>
> I'll clone that for QFixed.
Done. Also for qfloat16.
I've also updated the epic
(https://bugreports.qt.io/browse/QTBUG-104180) with information
regarding wg21.link/P2484 which aims to remove the "public members"
restriction, and which we may want to wait for.
My head starts to fill with lots of examples of types that would be
useful as template arguments: QOSVersion, QTypeRevision, ...
Speaking of which, I've looked at QTypeRevision now. The relational
operators are very complex, indeed. I think that's because the encoding
of unspecified major/minor version doesn't match the desired ordering:
// major 0 < unspecified major < non-0 major
// minor 0 < unspecified minor < non-0 minor
yet
enum { SegmentUnknown = 0xff };
If the encoding was, instead,
optional m{aj,in}orVersion() const {
switch (m_m{aj,in}or) {
case 0: return 0;
case 1: return std::nullopt;
default: return m_m{aj,in}or - 1;
}
we could probably = default op<=>. ... Ok, no, we'd also need to use
one uint16_t instead of two uint8_t's, because currently the
lexicographical sorting used by op<=> would be wrong for LE architectures.
Interestingly, the latter change could be done in a BC way, the former
cannot, though.
Thanks,
Marc
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] C++20 structural types (was: C++20 @ Qt)
Hi Thiago, On 04.11.22 16:49, Thiago Macieira wrote: > I've just hit this: should we make some of our very simple types even simpler > so they're structural types[1] and thus can be passed as template parameters? > > For example, QFlags. I've just tried it and I get: > > error: ‘QFlags’ is not a valid type for a template non-type > parameter because it is not structural > note: ‘QFlags::i’ is not public > > [1] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0732r2.pdf I wrote about this in the comparison sub-thread: On 03.11.22 10:40, Marc Mutz via Development wrote: > One can even now = default the equality operator. Then the compiler > creates one based on for member-wise equality. If all such members have > an = default'ed equality operator, and with a few other other > requirements, the type in question has Strong Structural Equality, and > thus can be used as arguments to non-type template parameters (NTTP). > QFlags and QFixed are examples where this might come in handy. There are > probably others, too. There's also https://bugreports.qt.io/browse/QTBUG-94266 I'll clone that for QFixed. Thanks, Marc ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] C++20 structural types (was: C++20 @ Qt)
On Freitag, 4. November 2022 21:47:14 CET Thiago Macieira wrote: > On Friday, 4 November 2022 10:38:30 PDT Allan Sandfeld Jensen wrote: > > Can we even do that, and still preserve ABI and API? > > I don't see why not. QFlags is already standard-layout, trivially copyable > and trivially destructible. Changing the member from private to public > won't affect any of those properties. Right, but it is only forward compatible, as making members public gives new API options. So okay for a minor release, but not for a point release that also needs to be backwards compatible. Allan ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] C++20 structural types (was: C++20 @ Qt)
On Friday, 4 November 2022 10:38:30 PDT Allan Sandfeld Jensen wrote: > Can we even do that, and still preserve ABI and API? I don't see why not. QFlags is already standard-layout, trivially copyable and trivially destructible. Changing the member from private to public won't affect any of those properties. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] C++20 structural types (was: C++20 @ Qt)
On Freitag, 4. November 2022 16:49:30 CET Thiago Macieira wrote: > I've just hit this: should we make some of our very simple types even > simpler so they're structural types[1] and thus can be passed as template > parameters? > > For example, QFlags. I've just tried it and I get: > > error: ‘QFlags’ is not a valid type for a template > non-type parameter because it is not structural > note: ‘QFlags::i’ is not public > > [1] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0732r2.pdf Can we even do that, and still preserve ABI and API? Best regards, Allan ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] C++20 structural types (was: C++20 @ Qt)
I've just hit this: should we make some of our very simple types even simpler so they're structural types[1] and thus can be passed as template parameters? For example, QFlags. I've just tried it and I get: error: ‘QFlags’ is not a valid type for a template non-type parameter because it is not structural note: ‘QFlags::i’ is not public [1] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0732r2.pdf -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
