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

[Smith Martin]

Then after we add QStringView, we will have QString for containing a string and QStringView for passing its contents out of Qt?

martin

________________________________________
From: marc at kdab.com <marc at kdab.com> on behalf of Marc Mutz <marc.mutz at kdab.com>
Sent: Friday, October 16, 2015 10:07 AM
To: Smith Martin
Cc: development at qt-project.org
Subject: Re: [Development] RFC: Proposal for a semi-radical change in  Qt       APIs taking strings

On Friday 16 October 2015 07:59:40 Smith Martin wrote:
> Can you refocus the discussion for everyone? For me at least?
>
> QString is my favorite class of all time. I use it every day in every
> program; it always works, and I never make a mistake.

Then you can continue to be blissfully ignorant of reality as you are :) If
you are a QString fanboy and don't care about 3rd-party code and/or efficiency,
then you can just continue as before.

> 1. What is the problem with QString that QStringView will solve?

TL;DR: Inefficient conversion from/to QString, leading to inefficiencies within
pure Qt-code and in particular when interfacing with 3rd-party code, BiC
issues,

> 2. Why can't QString be fixed?

Because it is a container, not an interface type.

An interface type needs to be BC across most of compilers and languages (incl.
C and - potentially Java).

A container needs to handle (as in own) memory. An interface type (quite
obviously, if it's to work with C, too) cannot.

> 3. What is a string view?

A pimped { QChar *begin, QChar *end; }

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 Experts