[Development] QtCS 2017 QtCore sessions
jeanmichael.celerier at gmail.com
Fri Dec 1 19:59:48 CET 2017
> (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
On Fri, Dec 1, 2017 at 7:26 PM, Thiago Macieira <thiago.macieira at intel.com>
> 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
> the ordering result. Since we don't yet have the spaceship operator, you
> to call the compare() function. But you can't do that in clean, generic
> 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
> 2021 or later (just look at how we have to build Linux binaries with GCC
> 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
> 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 at qt-project.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Development