[Development] QtCS 2017 QtCore sessions

[Marc Mutz]

On 2017-11-30 20:09, Thiago Macieira wrote:
> 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.

Don't go off on a tangent here. I used concepts syntax to keep the 
example simple. I can post with std::enable_if, if you prefer :)

Anyway, the point is the asymmetry of member functions. 
u"Hello".compare(string) does not compile in C++ (it does in Java), so 
everyone that wants to write a template like the op== above will have to 
re-invent qCompareStrings(). The Qt API rules stipulate that the common 
use case should be made simple (we do, we have member functions 
whereever we can add them), but make the rest possible. And that's where 
qCompareStrings() come in. It makes the remaining 5% (random number) 
possible.

>> 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.

And I would interpret the Qt API design rules differently: like 
qCompareStrings(), constexpr QSV ctors enable the remaining 5% of 
use-cases. If the standard equivalent wasn't constexpr all-over, one 
could maintain that what people don't know they will not miss. But 
std::string_view _is_ all-constexpr, and therefore (some) people will 
miss it. That leaves the question whether long raw strings passed to 
QSV(Char*) without also passing the length are the common use-case or 
whether the common use-case is that the user doesn't care. And I think 
that it's the latter, because off the top of my head, I can think of no 
situation where I actually would need the length calculation in QSV's 
ctor. The situation is a bit different in std::string_view where this 
ctor also receives all C string literals. We have a separate ctor for 
that in QSV, so we don't depend so existentially on the (Char*) ctor to 
be constexpr, but we also don't have a performance problem, since the 
frequency of calls to that ctor is very, very low. And there's the 
work-around to enable the 10% (random number) of users that see a 
performance problem with that ctor to call qustrlen() manually.

We should empower, not infantilise, the user.

> 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.

We all think we're smarter than the committee, yes. Maybe we are, but 
swarm intelligence suggests otherwise.

Thanks,
Marc