I drafted a QUIP that describes how to apply C++20 comparison to Qt classes:
https://codereview.qt-project.org/c/meta/quips/+/490932 It intentionally does not mention `qCompareThreeWay()` and `qComparesEqual()`, because these public APIs are not required for the internal implementation. ------------------------------ 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 Ivan Solovev via Development <development@qt-project.org> Sent: Thursday, September 21, 2023 11:10 AM To: development@qt-project.org <development@qt-project.org> Subject: Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt) > 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++. As you correctly pointed out, most of the developers will just use public operator==(), and, come C++20, operator<=>(). But I'd say that if someone wants to implement three-way comparison for their classes in C++17, then a bit better understanding of the language features is a reasonable expectation. At the same time, if we use Volker's suggestion and go with `compareThreeWay` and `comparesEqual` as the names for (1), I do not see any problems in implementing `qCompareThreeWay` as (4). Later we can also add `qComparesEqual` for consistency and even provide 3-arg overloads for string-like types, like Marc suggests. ------------------------------ 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 Ivan Solovev via Development <development@qt-project.org> Sent: Thursday, September 21, 2023 10:43 AM To: development@qt-project.org <development@qt-project.org> Subject: Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt) > 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