[Development] Use of Standard Library containers in Qt source code

[Marco Bubke]

> 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.io at qt-project.org> on behalf of Thiago Macieira <thiago.macieira at intel.com>
Sent: Tuesday, July 12, 2016 7:33:16 AM
To: development at 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 at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160712/299fd25f/attachment.html>