On Thu, 11 Jul 2019 at 18:43, Matthew Woehlke <[email protected]>
wrote:
> On 11/07/2019 05.05, Mutz, Marc via Development wrote:
> > There is a cost associated with another string class, too, and it's
> > combinatorial explosion. Even when we have all view types
> > (QLatin1StringView, QUtf8StringView, QStringView), consider the overload
> > set of QString::replace(), ignoring the (ptr, size) variants:
> >
> > {QL1V, QU8V, QSV, QChar} x {QL1V, QU8V, QSV, QChar}
> >
> > that's 16 overloads. And that's without a possible QUtf32StringView.
>
> So?
>
>
I have nothing to say in this discussion, but just want to throw in one
small hint/request/worry:
please, if it can be avoided, don't add yet another string-related class to
Qt. Knowing when to properly use QString, QByteArray, QLatin1String,
QStringLiteral, QStringRef and QStringView (I may have missed a few) is
already a challenge. And I imagine for people new to Qt it can even be a
strong deterrent (after all, strings are something you tend to use even in
a simple Hello World - the first app most people see or write in a new
language/ framework).
> The right way to handle this is for those methods to be templated, in
> which case a) the code only needs to be written O(1) times, not O(N)
> times, and b) users can potentially specialize for their own string
> types as well.
>
> If done cleverly, even the (pointer, size) variants should be able to
> wrap the arguments in a View, such that those method definitions are
> trivial.
>
> --
> Matthew
> _______________________________________________
> Development mailing list
> [email protected]
> https://lists.qt-project.org/listinfo/development
>
_______________________________________________
Development mailing list
[email protected]
https://lists.qt-project.org/listinfo/development
