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