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

[Knoll Lars]

On 22/10/15 10:56, "Paul Olav Tvete" <paul.tvete at theqtcompany.com> wrote:

>On Tuesday 20. October 2015 23.37.27 Thiago Macieira wrote:
>> Em qua 21 out 2015, às 06:29:30, Knoll Lars escreveu:
>> > As I remember it, the change from QSubString to QStringRef was a
>>simple
>> > API
>> > naming decision, i.e. independent of the implementation details.
>> 
>> Then it must be a coincidence that it changed internals more or less at
>>the 
>> same time.
>
>Both were committed at the same time (in change
>138d1ab051ed4934b303fa7a43a27dc4004e3ff9 for those who have access to the
>old 
>Qt history).  
>
>Date:   Mon Jan 15 14:59:53 2007 +0100
>Commit message: "Removed QSubString again, and introduced a lower-level
>class 
>QStringRef"
>
>QSubString had a QString::Data *d member, and the initial QStringRef had
>a 
>const QString *m_string, just like today.
>
>I have only skimmed the thread, so I'm probably misunderstanding
>something, 
>but I don't see how a QString pointer is that much safer than a Data
>pointer, 
>or a QChar pointer.

Unless you participate in the ref counting it’s only slightly safer. It’s
safe against modifications of the string that do not shrink it’s length.
> 
>
>A safe class would use the implicit sharing by keeping a QString member,
>but I 
>don't know how that would impact performance.

Not a good idea IMO, as you’ll need to increase and decrease the refcount
of often trivial operations. In addition, I think a QChar pointer + length
is a better idea, as it also allows wrapping data that’s not contained in
a QString.

Cheers,
Lars