[Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings
Konstantin Ritt
ritt.ks at gmail.com
Thu Oct 15 14:52:46 CEST 2015
2015-10-15 11:00 GMT+03:00 Bubke Marco <Marco.Bubke at theqtcompany.com>:
> On October 15, 2015 08:45:30 Knoll Lars <Lars.Knoll at theqtcompany.com>
> wrote:
>
> > On 14/10/15 23:51, "Bubke Marco" <Marco.Bubke at theqtcompany.com> wrote:
> >
> >>On October 14, 2015 23:10:26 Thiago Macieira <thiago.macieira at intel.com>
> >>wrote:
> >>> Qt does not have to provide a comparator that operates on something
> >>>other than
> >>> its native string type.
> >>
> >>Isn't Qt a framework to help developers? Sorry your argumentation is
> >>sounds not very empirical.
> >
> > Of course our aim should be to help developers. But there will always be
> > some use cases which we will not cover. The question is whether this is
> > one of them or not.
>
> Most file and network content is in utf 8, databases too. It has simply a
> size and performance advantage for most cases. You have not so many cases
> where you have pure Chinese signs in an text. Mostly it is an mixture. In
> Linux, which is very important in embedded, utf 8 dominates ťhe APIs. Ask
> your self if we don't want support that. We could start simply and expand
> slowly. If the standard library would support utf 8 collations on all
> platforms very well we could skip it but today you have to do your own
> solutions again and again.
>
For everything but US-ASCII / Latin-1, UTF-8 isn't faster than UTF-16 (feel
free to compare their complexity against UTF-32).
And why "pure Chinese signs" again? Did you ever look into the Unicode's
Scripts.txt [1], for example? It clearly shows UTF-16 covers [almost] all
spoken languages, without any performance hits (in compare to UTF-8), and
all we have to pay is an extra byte per every Base Latin character (in
compare to UTF-8, again).
[1] http://www.unicode.org/Public/8.0.0/ucd/Scripts.txt
Regards,
Konstantin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20151015/9d334df5/attachment.html>
More information about the Development
mailing list