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

[Thiago Macieira]

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