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
