[Development] Use of Standard Library containers in Qt source code
thiago.macieira at intel.com
Tue Jul 12 07:33:16 CEST 2016
On terça-feira, 12 de julho de 2016 00:20:01 PDT Cristian Adam wrote:
> Their latest presentation
> y/copperspice_the_next_generation_of_signals.pdf> has
> at page 6 this:
* 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
* 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
* Use C++ native pointers: granted, that's also the reason why we're not
reimplementing std::unique_ptr or extending QScopedPointer to have move
* 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
More information about the Development