> (just look at how we have to build Linux binaries with GCC 4.8). Isn't it possible to use a newer GCC but to tell it to use GCC 4.8's ABI ? eg to target GCC 4.8, by using -fabi-version=2 -D_GLIBCXX_USE_CXX11_ABI=0
Best, ------- Jean-Michaël Celerier http://www.jcelerier.name On Fri, Dec 1, 2017 at 7:26 PM, Thiago Macieira <thiago.macie...@intel.com> wrote: > On Friday, 1 December 2017 01:31:18 PST Marc Mutz wrote: > > > Once those operator<=> are there, what benefit is there in having the > > > API > > > public and documented? > > > > The spaceship operator solves the problem for qCompareStrings(). One > > could say we already have all relational operators for all combinations > > of string-like objects to solve it for the user _now_, but > > qCompareStrings(), like operator<=>() return the full information, while > > relational operators only return a subset. You know that, I know. I'm > > just mentioning it for completeness sake. > > Ok, so your case is when you have two string-like objects and you want to > get > the ordering result. Since we don't yet have the spaceship operator, you > have > to call the compare() function. But you can't do that in clean, generic > code > because you don't know if the first argument is an actual QString or > QStringView, or if it's just a char16_t literal. > > Is that it? > > Why can't they write > > QStringView(s1).compare(s2) ? > > > And we have more than qCompareStrings(). How does operator<=> help with > > qFindString()/qIndexOf() (which is still missing)? Answer: it doesn't. > > There's no infix notation for find-in-string. And there probably never > > will be (fancy proposing operator=~, anyone?). > > In both cases, explain why we need to provide that. Why can't they write > > QStringView(s1).indexOf(s2) ? > > > Ah, but you said that the flaw was in the _standard_. But what you show > > are sub-optimal compiler implementations. There's nothing in the > > standard that prevents a compiler to implement char_traits::length() as > > a compiler intrinsic that can have different backends for constexpr and > > runtime evaluation. > > The flaw is in the standard because it does not allow me to implement an > optimised version using whichever tools I want to. > > > So, would the following be acceptable: > > > > 1. QSV uses char_traits<char16_t>::length() to calculate the length > > (that was my initial implementation, but it's constexpr only starting > > with C++17). Then QSV(Char*) is only constexpr in C++17. I can live with > > that. > > No, because... > > > 2. You/Intel work on the compiler vendors to get > > char_traits<char16_t>::length() implemented as an intrinsic, with SIMD > > at runtime and compiler magic at compile-time? > > We should do that anyway, but depending on it means we'll have performance > in > 2021 or later (just look at how we have to build Linux binaries with GCC > 4.8). > > The flaw exists today. My choice for fixing it is to sacrifice the part we > don't really need: the constexprness. > > > Then we fix the problem where it should be fixed, and just piggy-back on > > the more general solution. And it's easy to sell to QSV users why that > > ctor is not constexpr until C++17 (and we don't even need any #ifdefery > > in the implementation). > > > > What do you think? > > We should fix the standard and we should help fix the implementations. But > I'm > not accepting a performance drawback for 3 or more years until then. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development >
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
