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
smime.p7s
Description: S/MIME cryptographic signature
-- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
