On 21/10/15 08:37,
"development-bounces+lars.knoll=theqtcompany....@qt-project.org on behalf of
Thiago Macieira"
<development-bounces+lars.knoll=theqtcompany....@qt-project.org on behalf of
thiago.macie...@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
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
