On 2020-05-13 11:53, Ville Voutilainen wrote:
On Wed, 13 May 2020 at 12:46, Marc Mutz via Development
<development@qt-project.org> wrote:
In the not so hypothetical case that Qt is used to visualize results
of
some business calculations, chances are that thrid-party libraries
will
use std::string or std::u16string, and not QString, requiring the use
of
QString::fromStdString() to pass these to a QString API. Had the API
taken QStringView, no extra code would have been necessary.
Wait, what? How can QStringView view a std::string?
Touché.
I was a bit sloppy there.
There was an idea floating around this mailing-list next last year or
so, to have one string class for different encodings. Of course, in and
of itself, that's nonsense, because performance is not predicatable
anymore. But for a really user-friendly API (as opposed to
implementation-friendly), we could have most functions that now take
QString, and are not candidates for overloading on QStringView,
QUtf8StringView and QLatin1StringView, take a variant<QStringView,
QUtf8StringView(, QLatin1StringView)>-like container, called QAnyString.
They would then internally convert this into the encoding they need. I
believe this would be an acceptable compromise between the
many-small-narrowly-focused-classes and
one-string-class-to-rule-them-all camps, as it would reduce the number
of overloads in non-performance-critical areas while maintaining the
flexibility that taking QString now offers. It's how multi-arg() is
currently implemented, except it's private API now, and not anywhere
near something that could become public API.
Thanks,
Marc
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
