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

[Knoll Lars]

On 21/10/15 08:37, "development-bounces+lars.knoll=theqtcompany.com at qt-project.org on behalf of Thiago Macieira" <development-bounces+lars.knoll=theqtcompany.com at qt-project.org on behalf of thiago.macieira at intel.com> 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.

Possible. I have to admit that I don't recall all the details anymore. I can try to look up the old commit logs in case we think this is important.

> 
>> 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.

Do you remember what broke?

Cheers,
Lars