[Development] Feature Freeze Exception: QStringView

[Marc Mutz]

On Friday 03 February 2017 09:29:22 Thiago Macieira wrote:
> On sexta-feira, 3 de fevereiro de 2017 08:49:24 PST Marc Mutz wrote:
> > When the QString overload is replaced by a QStringView one, these calls
> > become errors. I don't mean to say that's a good thing going forward into
> > Qt 6, but I do say that having this option (and nothing more is being
> > discussed atm) will be very helpful in porting existing users of QL1S and
> > C
> 
> > string literals to QStringView:
> Your tests do not take QString improvements in Qt 6 into account.
> 
> extern void setLabelQStringCRef(const QString &);
> void callSetLabelQStringLiteral() {
> 	setLabelQStringCRef(QStringLiteral("&OK"));
> }

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?

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

The test for -1 in my assembly listing also always succeeds on a moved-from 
QString, but so far I have failed to make the compiler drop the dead code. I 
tried Q_ASSUME in sharedNull() to make it known what that QArrayData's ref-
count was, but no matter how I formulate the inline part of the QString dtor, 
the call to deallocate() never vanished from the assembly. On GCC 7, with -O3.

> .L1:
>         addq    $32, %rsp
>         popq    %rbx
>         ret
> [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). My listing contained it, because the compiler 
emitted it, with the unchanged flags for tst_qstringview, which, apart from 
enabling C++14, does not change the default flags for testcases, and probably 
user projects, too.

> Don't get me wrong: I like QStringView improvements. But we're going to
> improve QString too.

And I like the QString improvements. It will make substringing cheap, afaiu, 
and if we hopefully get SSO, QStringView-setter overhead will be greatly 
reduced. The two work hand-in-hand.

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts