> Why would we want UTF-8? There's no native type for it, unlike UTF-16's > char16_t. And ALL the good Unicode-capable API in most OSes uses UTF-16 (Java, > ICU, Win32, Cocoa, all are UTF-16; POSIX's wide-char API is neither good nor > guaranteed to be UTF-32).
UTF-8 is used by many libraries and converting between UTF-16 and UTF-8 makes things not faster or better. If you work with text which is annotated with ASCII, which is quite common today, the advantages of Utf8 looks quite compelling. But without changing QString to UTF-8 our UTF-8 support could be much better . For example we convert mostly to a QByteArray which has to be copied again because we have move the ownership of that string to API which is not supporting QByteArray. In that case it would be already nice that you would have something like QByteArray::takeData(). And this is only one case. Lets face it, the world is much bigger than Qt, and I think there is much to gain if we integrate better with alien libraries. Actually as I used Qt in the nineties it was my impression that Qt had that mindset but than it changed gradually. ________________________________ From: Development <development-bounces+marco.bubke=qt...@qt-project.org> on behalf of Thiago Macieira <thiago.macie...@intel.com> Sent: Tuesday, July 12, 2016 7:33:16 AM To: development@qt-project.org Subject: Re: [Development] Use of Standard Library containers in Qt source code On terça-feira, 12 de julho de 2016 00:20:01 PDT Cristian Adam wrote: > Their latest presentation > <https://github.com/boostcon/cppnow_presentations_2016/blob/master/00_tuesda > y/copperspice_the_next_generation_of_signals.pdf> has > at page 6 this: Criticism: * Qt's dependency on qmake: that's only for building Qt itself, not for your application. Otherwise, we could always criticise any library for choosing to use buildsystem X instead of Y. * Remove moc: why? Moc has a very important use besides signals, that being of reflection of C++. Until at least C++ 2020, but most likely WAY further, there's no replacement for that. Therefore, removing moc is removing important functionality. Let's see CS implement QtScript, QtDBus and QtQml without moc... * Use native C++ atomics: done in Qt 5.7, except for MSVC which doesn't implement it properly. * Signal / slot delivery as a separate library: interesting, I'll give CS that, but not sure what the value of this is. * Containers: leveraging STL only makes sense if we drop implicit sharing. There are many arguments in favour and against doing that, which I will not get into. What I will say: doing implicit-sharing with STL is the worst of both worlds. * Use C++ native pointers: granted, that's also the reason why we're not reimplementing std::unique_ptr or extending QScopedPointer to have move semantics. * Refactor QString: huh? > What would QString refactor would bring? UTF-8? QStringView? Why would we want UTF-8? There's no native type for it, unlike UTF-16's char16_t. And ALL the good Unicode-capable API in most OSes uses UTF-16 (Java, ICU, Win32, Cocoa, all are UTF-16; POSIX's wide-char API is neither good nor guaranteed to be UTF-32). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
