[Development] Feature Freeze Exception: QStringView

[Thiago Macieira]

On sexta-feira, 3 de fevereiro de 2017 12:59:19 PST Marc Mutz wrote:
> QStringLiteral is not what most people use. It's too verbose. They use
> "&OK", cf. our tests and, to a lesser extend, because we encourage tr()
> there, examples and docs.
> 
> u"&OK", however, has almost no readbility overhead compared to "&OK", or
> even a hypothetical "&OK"_qs, which would probably have to be written
> u"&OK"_qs, anyway?

u"&OK"_q (no need for s) would be just a short way to write QStringLiteral and 
would return the below code. The only reason that we haven't implemented it 
yet is because the C++ committee dropped the most interesting feature of UDLs 
prior to C++11, recognised that before C++14 but hasn't brought it back yet. 
There was a discussion on compile-time strings being equivalent and I remember 
being swayed by the arguments, but I don't  remember the technique now.

> > _Z26callSetLabelQStringLiteralv:
> >         pushq   %rbx
> >         subq    $32, %rsp
> >         movq    _ZN10QArrayData18shared_static_dataE at GOTPCREL(%rip), %rax
> >         movq    %rsp, %rdi
> >         movl    $3, 16(%rsp)
> >         movq    %rax, (%rsp)
> >         leaq    .LC0(%rip), %rax
> >         movq    %rax, 8(%rsp)
> >         call    _Z19setLabelQStringCRefRK7QString at PLT
> >         movq    (%rsp), %rax
> >         testl   $512, (%rax)
> >         je      .L12		# always fails
> 
> But jumps to code that is emitted anyway, bloating the executable, reducing
> effective icache-size-

True. As long as QString can own data, it needs to know whether the data it 
has is yours or not. I've tried to make the shared_static_data static be 
constexpr, but the problem is the called function:

	const is not const

That is, the called function may const_cast the object passed by reference and 
modify the d pointer. So long as C++ allows this and we don't have a way to 
inform the compiler that a parameter (including the this parameter) is 
*really* const, this useless code emission will continue to happen.

> > [followed by exception handling code irrelevant for us]
> 
> I disagree. The exception code is not irrelevant for our users (and not for
> us, either, e.g. in QtCore). 

It's irrelevant when the function called is one of ours, in a library of ours 
that got compiled with -fno-exceptions. It'll never throw. Even the few 
libraries we compile with exceptions will never throw. *Especially* the 
functions that would not allocate memory anyway, just increase a refcount.

And QStringView overloads are likely to be exclusively found in Qt API, for 
the first three years of its existence, to an approximation of 95%.

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