> 12 мая 2020 г., в 09:49, Lars Knoll <lars.kn...@qt.io> написал(а):
>
> Hi all,
>
First of all, the plan sounds great!
>
> Most other classes:
>
> * Only take and return QString
> * Exceptions can be done where significant performance gains can be
> demonstrated and the API will by design not require a copy of the data (e.g.
> XML writer, stream writers, date time handling)
Let me disagree here. The decision should be taken on the fact if the object
takes ownership of the string (and thus QString is used) or it only «looks»
into it.
Otherwise, QString gets propagated all over the place:
void addSuffix(const QString &suffiix) // can’t use view here!
{
m_memberString.append(suffix); // no QStringView overload, can’t use
QStringView in the API
}
Ok, we aim to have an QString::append(QStringView) overload, so the example is
not that good.
Another one:
QMimeType findMimeType(const QString &name) // can’t use view here!
{
QMimeDataBase().mimeTypeForName(name); // no QStringView overload, the API
propagates QString through all the code
}
I hope the idea is clear.
PS: it is not that easy to fix QMimeDataBase to take QStringView (I looked into
the possibility), but the aim should be to take QStringView where it is
possible, not where it is *faster*.
Ivan
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
