On October 14, 2015 23:10:26 Thiago Macieira <thiago.macie...@intel.com> wrote:
> On Wednesday 14 October 2015 20:52:12 Bubke Marco wrote: >> On October 14, 2015 22:13:11 Thiago Macieira <thiago.macie...@intel.com> > wrote: >> And I don't want an utf 8 baked >> QString. For my use cases implicit sharing is overkill. Move semantics >> would be enough. I want localAwareCompare(const char *s1, const char *s2). > > Do it on your own. You just said that ICU has the function you want, so use > it. So Qt is always shipping with ICU? > 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. > >> Maybe windows and mac os will bring support to the standard library so we >> don't need it but in the mean time it would be very helpful. >> >> A utf 8 based QTextDocument would be maybe nice too. > > What for? It needs to keep a lot of extra structures, so the cost of > conversion and extra memory is minimal. And besides, QTextDocument really > needs a seekable string, not UTF-8. Is UTF 16 seekable? You still have surrogates and you can merge merge code points. Lets describe an example. I send the QTextDocument content to an library which expect utf8 content and gives me back positions. This gets interesting if you use non ASCII signs. Actually the new clang code model works that way. > > Even if we provide UTF-8 support classes, those will not propagate to the > GUI. > Forget it. What about compressing UTF 16 like python is doing it for UTF 32. If you are only using ascii you set a flag and you can remove all that useless zeros. It would be have implications for data() but maybe we should not provide access to the internal representation. If you use UTF 32 as a base you don't need anymore surrogates. _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
