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

[Paul Olav Tvete]

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. 

A safe class would use the implicit sharing by keeping a QString member, but I 
don't know how that would impact performance.

- Paul