[Development] QtCS 2017 QtCore sessions

[Jean-Michaël Celerier]

> (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.macieira at 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 at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20171201/c88d09ef/attachment.html>