[Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

[Thiago Macieira]

On Wednesday 14 October 2015 20:52:12 Bubke Marco wrote:
> On October 14, 2015 22:13:11 Thiago Macieira <thiago.macieira at intel.com> 
wrote:
> > On Wednesday 14 October 2015 17:55:34 Bubke Marco wrote:
> >> Think about a local aware compare which is called very very often. You
> >> don't want malloc in between. In in most cases you get an const char* or
> >> const shor* in this cases It would be nice if your interface would
> >> support UTF-8 and not only UTF-16.
> > 
> > Three of the four implementations of QString::localeAwareCompare operate
> > on
> > UTF-16 (Win32 CompareStringW, CoreFoundation's CFStringCompare and ICU
> > ucol_strcoll). That's another reason for keeping QString as UTF-16.
> 
> Thiago, to my understanding ICU is supporting UTF 8 too. I don't ask for UTF
> 8 support because I like it but I need it. 

There's ucol_strcollUTF8 since ICU 50, indeed. Quite a few systems are still 
running older versions today, but that wouldn't be an argument for Qt 6.

> 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.

Qt does not have to provide a comparator that operates on something other than 
its native string type.

> 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.

Even if we provide UTF-8 support classes, those will not propagate to the GUI. 
Forget it.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center