[Development] QtCS 2017 QtCore sessions

[Thiago Macieira]

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