[Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)

[Ivan Solovev]

Marc wrote:
> Why do you say it only applies to partial ordering? Do we already match
> the values, other than that of std::partial_ordering::unordered?

Yes, we do.

Thiago wrote:
> We can also just be evil and use bit_cast

Why is that evil? Reading about std::bit_cast, this can be an option, if we
guarantee that sizeof(Qt::*_ordering) == sizeof(std::*_ordering).
Which is, probably, already true.

Thanks,
Ivan

________________________________
From: Development <development-bounces at qt-project.org> on behalf of Marc Mutz via Development <development at qt-project.org>
Sent: Thursday, November 9, 2023 8:17 AM
To: development at qt-project.org <development at qt-project.org>
Subject: Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)

On 08.11.23 16:46, Thiago Macieira wrote:
> On Wednesday, 8 November 2023 00:38:32 PST Marc Mutz via Development wrote:
>> Let's not mix up topics here...
>>
>> 1/ We're not responsible for the ABI of third-party libraries. As long as
>> we document that the return type of a non-exported inline functions
>> changes, then it's SEP if someone else writes code that ties their ABI
>> to the result type of such functions.
>
> Fair, but we are responsible if we make it difficult for them to do this, or
> make it trivial for them to have the problem without knowing that they have
> it. That was the issue with std::string in libstdc++: it kept libstdc++ BC,
> but broke everyone downstream of it.

std::string is a type, but we're talking about function return types.
Oranges and apples. Naturally the impact of the former is orders of
magnitude larger than that of the latter.

>> That leaves 2/ the mythical "merge of inline functions from different
>> libraries" and 3/ "mixing of C++ versions within the same executable"
>> situations.
>>
>> I agree that the latter is a problem; I stated as much in my previous
>> email, and gave (1) and (3) as solutions.
>>
>> But I still don't see how the former is a problem, or, if it is, why (3)
>> (BC between {std,Qt}::_ordering) doesn't fix it, too.
>
> I think it's acceptable for us to change the return type of a function so long
> as it's getting a new mangling. That means it can apply to any regular
> function, but not operators. Then again, all of the latter return bool except
> for operator<=> so there's no problem there either.
 >
> But why take the risk? The performance impact is minimal, because it only
> applies to partial ordering, while the vast majority of types are fully
> ordered.

Why do you say it only applies to partial ordering? Do we already match
the values, other than that of std::partial_ordering::unordered?

> The impact of QAnyStringView in any API is greater.

Unrelated.


I do note that you didn't attempt to poke holes into my documentation of
my understanding of the "merge of inline functions from different
libraries" issue.

To TL;DR: it: I believe there is no way that an (application or) library
can call another (dynamic) library's implementation of a non-exported inline
function. It will always contain (and call) its own copy of the
non-exported inline function.

Independent of the resolution of the C++20 comparison return types, I
think it's vital to come to a common understanding of whether there is
an actual issue with non-exported inline functions in ABIs (and then
document it in the KDE BC wiki).

Thanks,
Marc

--
Marc Mutz <marc.mutz at 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 at qt-project.org
https://lists.qt-project.org/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20231109/9074ae16/attachment-0001.htm>