Hi, > Given the state of https://codereview.qt-project.org/c/qt/qtbase/+/481410/3 > right now (needs rebase, doesn’t build with either C++17 or C++20 for me on > macOS with apple’s clang)
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. > O = compareThreeWay, following std::compare_three_way > (https://en.cppreference.com/w/cpp/utility/compare/compare_three_way) > E = comparesEqual > > The vast majority of code will use operators to compare two objects. > Code that somehow needs the concept spelled out can type it out as well. > In contrast to `swap` we don’t need to be short here, given that the > operator-shorthand exists. Nice suggestion, thanks! Works for me! > why do we need qEquals? Actually, I have the same question. That's why I wrote that we might decide to not provide (4) at all. We have deprecated qSwap() and explicitly recommend using using std::swap; swap(lhs, rhs); instead. So why should we act differently for comparison? ------------------------------ 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 Volker Hilsheimer via Development <development@qt-project.org> Sent: Wednesday, September 20, 2023 11:53 AM To: Marc Mutz <marc.m...@qt.io>; development@qt-project.org <development@qt-project.org> Subject: Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt) On 19 Sep 2023, at 15:49, Marc Mutz via Development <development@qt-project.org> wrote: So I ask: Please let us roll out the framework with one of equal/eq/order/ordering/cmp (your choice, but quickly!), to set a status quo against which to benchmark any potentially-superior solutions, and then the ML can finish bikesheddding and if the discussion yields something better, I think I speak for Ivan, too, when I say that we're committed to porting to that. Thanks, Marc Given the state of https://codereview.qt-project.org/c/qt/qtbase/+/481410/3 right now (needs rebase, doesn’t build with either C++17 or C++20 for me on macOS with apple’s clang), my suggestion would be to go “very explicit" with the names for O and E, at least for the time being. O = compareThreeWay, following std::compare_three_way (https://en.cppreference.com/w/cpp/utility/compare/compare_three_way) E = comparesEqual The vast majority of code will use operators to compare two objects. Code that somehow needs the concept spelled out can type it out as well. In contrast to `swap` we don’t need to be short here, given that the operator-shorthand exists. Once the chain of commits is up-to-date it will be easier to play around with alternatives, to see if we can come up with a technical solution that allows us to use `equals` and `compare` as names for E and O, as those are established APIs in Qt. You lost me here, but I assume that you're talking about what I call (4). There must be _one_ global template. It calls (2) or (3) via (1). Everything else is a novel idea that must argue against 30 years of C++ and 30 years of Qt experience. qFoo would be that (4). A class-static cannot be that (4). Yes, I’m not questioning that we need Qt::equals. But do we need (4)? you marked it as optional yourself. If we can have (1), i.e. using Qt::equals; equals(a, b); why do we need qEquals?
-- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
