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

[Thiago Macieira]

On Wednesday, 8 November 2023 23:17:45 PST Marc Mutz via Development wrote:
> 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.

std::string and std::__cxx11::string are different types, but someone changed 
which one got selected.

> > 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?

Yes. It's always -1, 0 and 1 for all three Standard Libraries.

https://github.com/gcc-mirror/gcc/blob/releases/gcc-13.2.0/libstdc%2B%2B-v3/
libsupc%2B%2B/compare#L51-L53
https://github.com/llvm/llvm-project/blob/llvmorg-17.0.4/libcxx/include/
__compare/ordering.h#L25-L33
https://github.com/microsoft/STL/blob/main/stl/inc/compare#L43-L45

> 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.

You didn't ask anything.

> 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.

That's only partially correct.

All libraries will contain out-of-line copies of any inline functions they 
didn't inline. This portion of your assertion was correct.

But if the symbols are globally visible (ELF visibility STV_DEFAULT), the 
dynamic linker will resolve all calls to the same symbol in one of the 
libraries, whichever one got loaded first by the depth-first library search and 
load order.

> 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).

The documentation there is correct: you can change inline functions and 
uninline them so long as the old copy can keep on being called. That says 
nothing about changing the function's return type or the layout of the type it 
does return.

But yes we should add to it.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5163 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20231109/dcbad83f/attachment.bin>