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

[Thiago Macieira]

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.
 
> The reason a String pointer is in there was due to an attempt to make this
> class a bit safer. As long as we guaranteed the lifetime of the underlying
> String, accessing the string ref should be ok. In hindsight, I do think
> this was a mistake, as this safety doesn't give you a whole lot. In
> practice, you couldn't modify the underlying Qstring anyway, so we could
> have simply used a QChar pointer and a length. That certainly would have
> been more flexible and would have helped us today.
 
> So I'd agree that one could use a QStringView in the XML parser today.
> QStringRef is doing exactly the same, but has the disadvantage of requiring
> a pointer to a QString. This works in the parser, as it keeps the whole
> string in memory for as long as parsing is ongoing, and you are supposed to
> consume the returned stringref. But I would not recommend using
> QStringRef/QStringView as a return value in almost all other cases.

That doesn't work. I've tried to change QStringRef and it broke in a lot of 
places.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center