I feel we're turning in circles here, so let me give a rundown of what I
thought we might meet at:
- Introduce Qt::{partial,weak,strong}_ordering
- BC and SC-as-much-as-possible to std::*_ordering
- Qt 7: Qt::foo_ordering becomes a typedef for std::foo_ordering,
like QPair in Qt 6
- QPartialOrdering stays as-is
- except it gets implicit conversions to Qt::_ordering types
- (undecided) ditto _to_ Qt::_ordering types
This means QVariant and QMetaType keep using QPartialOrdering, but
that's ok, they're anyway type-erased, so some overhead is expected.
QVariant, in particular, only has a static compare() function that
returns QPartialOrdering. An eventual compareThreeWay() would return
Qt::partial_ordering.
All other std::regular Qt classes will be using the new types (or, if
helper functions are inline and we compile in C++20 mode, the std types
directly).
On 14.11.23 18:20, Thiago Macieira wrote:
> On Tuesday, 14 November 2023 08:25:34 PST Ivan Solovev via Development wrote:
>>> 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.
>
> That boat sailed in 6.1 because QPartialOrdering is already used in QMetaType
> and QVariant API/ABI.
As per the above, these classes can continue to use QPO. QVariant, in
particular, when ported to the new macros, will use Qt::partial_ordering
in compareThreeWay() and QPO in compare(). Shit happens.
> Ideally for new out-of-line APIs, we could return a type that is ABI-
> compatible with std::partial_order.
That are the Qt::_ordering types, yes.
> But how many of those are we going to get?
Every ordered Qt class. I didn't count, but sufficiently many to matter.
>> 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).
>
> Yes, but the impact only applies to when it needs to translate from out-of-
> line to out-of-line. If either side is inline, it'll do the right thing on its
> own.
Yes. If either side is inline, you still get the conversion operators
emitted in debug mode, which Qt tends to optimize for, too. That's one
of the reasons why, even with {std,Qt}::_ordering types being BC to each
other, it makes sense to return std in C++20 builds and Qt in C++17 builds.
Thanks,
Marc
--
Marc Mutz <marc.m...@qt.io>
Principal Software Engineer
The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
www.qt.io
Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht Charlottenburg,
HRB 144331 B
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
