> I have just rebased the chain on top of the latest dev and fixed the issue > with qfloat16 and -Wfloat-equal. > Now it builds fine for me locally on Linux with GCC. Started a full pre-check > in the CI to test other configurations. > I'll keep an eye on the pre-check results and try to fix any other errors, > if they occur.
The qfloat16 patch does have some issues, because MSVC behaves differently from other compilers. That's something that needs a deeper investigation. Meanwhile, the full CI pre-check for the previous patch in the chain has completed successfully. So, you can use https://codereview.qt-project.org/c/qt/qtbase/+/479395 to test the approach. ------------------------------ 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, September 21, 2023 2:22 AM To: development@qt-project.org <development@qt-project.org> Subject: Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt) On Wednesday, 20 September 2023 02:53:37 PDT Volker Hilsheimer via Development wrote: > If we can have (1), i.e. > > using Qt::equals; > equals(a, b); > > why do we need qEquals? See my other email: the (1) is not discoverable, teachable, or particularly understandable by average C++ developers. It is not a good corner of C++. (4) (the convenience function) is what users expect. Except that we don't need it to be called qEquals, because we have an even better name for it: operator== -- 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