[Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

[Branislav Katreniak]

>
> > Non-owning QString can be created with special static QString method. It
> > stays non-owning only while being passed through const &. Code that cares
> > about keeping QString in view mode, must stick to const QString & all the
> > time. Copy assignment on non-owning QString results in owning QString -
> it
> > triggers deep copy into newly created shared data.
>
> Ok, I understand the difference, but why do you want this behaviour? BTW,
> this
> is the unsharable strings that we're getting rid of.


My intent was to think a while whether it can be used instead of
QStringView.


> 2) it's outside the d pointer, which means that
>  a) it doesn't need to allocate memory
>  b) we need to extend QString to be:
>   { QArrayData *d; ushort *b; qsize size; int flags; }
>   (24 bytes if qsize is 32-bit on 64-bit platforms; 32 if it is 64-bit;
> always
>    16 bytes on 32-bit platforms)
>
>
I was thinking about using 2 lowest bits of one of QString pointers.


> Either way, the existence of the flag means that every QString
> copy-assignment
> needs to check this flag, instead of simply incrementing the refcount if d
> is
> not null and being done with it. That means code bloat for the deep copy
> showing up everywhere.
>

If whole copy assignment including ref counting is inlined, then I agree
that this change would generate a lot of code bloat. Is it possible to
inline only the trivial QString copy (SSO case, pointer into text section
case)? Those are the only really fast paths. And to do ref counting and and
deep copy in non-inlined function? I don't have any feeling whether the
resulting generated code would be bigger / smaller and how big is the cost
of function call compared to ref counting. I am afraid that this is a no go.


> I really don't want the unsharable flag.
>

I fully agree that it is unacceptable to generate more code in very copy
assignment.

I even don't see any use case for this optimization in our project. All our
non-Qt strings are utf-8 encoded. But I am looking forward for SSO. That
can help us. As we don't care about backward binary compatibility, we would
benefit from an opt-in option to use it sooner than Qt6 :).

Kind regards
 Brano
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20151017/3b862db3/attachment.html>