[Development] QtCS 2017 QtCore sessions

[Thiago Macieira]

On quinta-feira, 30 de novembro de 2017 10:53:33 PST Marc Mutz wrote:
> What's wrong with str.compare()?
> 
> Do these two quotes somehow fit together?
> 
>    template <StringLike LHS, StringLike RHS>
>    bool operator==(const LHS &lhs, const RHS &rhs)
>    { return qCompareStrings(lhs, rhs) == 0; }
> 
>    template <StringLike LHS, StringLike RHS>
>    bool operator==(const LHS &lhs, const RHS &rhs)
>    { return lhs.compare(rhs) == 0; }
> 
>    if (u"Hello" == string) ~~~

I don't see how this problem can't be solved. We don't need templates with 
StringLike concepts. Not to mention we can't really rely on them in Qt for the 
next 10 years, so if you want to write that last line of code, we'll need a 
solution without concepts.

> 2. So ok, performance matters. But a flexible interface matters too. You
> might not use compile-time string manipulation, but people do. They
> write compile-time JSON parsers. Anyway, assuming you are right (and I
> don't think you are, here), where are your numbers that show that the
> frequency of calls to the QStringView(Char*) ctor multiplied with the
> performance increase of out-of-line SIMD code multiplied by the average
> length of strings is so large as to warrant dropping support for
> compile-time string manipulations and std compatibility? Show them, and
> then we'll discuss it again.
> 
> IMNSHO, absent proof to the contrary, you are optimizing an edge case
> here, an edge case that people can easily fix by using
> 
>     auto s = QStringView{s, qustrlen(s)};
> 
> manually when they expect large strings. The missing constexpr is not so
> easily obtained than the SIMD length calculation.

This was a judgement call. The C++ standard needs to be fixed, so I am doing 
what I think is the correct direction: performance first.

API parallelism with the Standard Library is not required where the standard 
library makes mistakes. Requiring constexpr for calculating string lengths is 
one where I think it made a mistake. Therefore, I will not accept that as an 
argument.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center