> The ABI functions can return one of these other types: > bool (for equality comparisons) > int (for non-partial ordering) > QPartialOrdering (for partial ordering)
IIUC, returning QPartialOrdering is exactly what we want to avoid, due to the std::partial_ordering -> QPartialOrdering (and reverse) conversions. As we figured out earlier in this discussion, by making Qt::partial_ordering binary compatible with std::partial_ordering, we will allow the compiler to optimize the code and avoid the conversions (specially if we use std::bit_cast). Thanks, Ivan ________________________________ From: Development <development-boun...@qt-project.org> on behalf of Thiago Macieira <thiago.macie...@intel.com> Sent: Tuesday, November 14, 2023 5:07 PM To: development@qt-project.org <development@qt-project.org> Subject: Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt) On Tuesday, 14 November 2023 04:17:18 PST Marc Mutz via Development wrote: > It's dangerously close to q20, yes, but q20 types switch at compile-time > between std and fall-back types, which means they cannot be used in the > ABI (yes, I used qxp::function_ref in QTestLib, but that doesn't have a > `using std::...`, yet, so we're still ok, and QTestLib doesn't have BC > constraints). Actually, how about we do exactly that: we DO NOT use them in the ABI and thus we DO use std:: types when compiling in C++20 mode. We can only use them in inline-only functions. The ABI functions can return one of these other types: bool (for equality comparisons) int (for non-partial ordering) QPartialOrdering (for partial ordering) -- 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
