[Development] char8_t summary?

Tomasz Siekierda sierdzio at gmail.com
Thu Jul 11 21:42:59 CEST 2019

On Thu, 11 Jul 2019 at 18:43, Matthew Woehlke <mwoehlke.floss at gmail.com>

> 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
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190711/7d651ef4/attachment.html>

More information about the Development mailing list