Qt Contributor Summit 2019 - QtCore: Difference between revisions
No edit summary |
No edit summary |
||
| Line 7: | Line 7: | ||
== Containers == | == Containers == | ||
QList = QVector by default in Qt 6 | |||
s/QList/QVector/g before Qt 6 releaase to avoid merging nightmare | |||
Not sure if to keep Qt5List. We need more evaluation about how much code breaks (e.g. when Creator, KDE port it) | |||
QPair=std::pair => no brainer | |||
QHash in terms of std::unordered_map: Lars, Peppe experimented on it, it "works", esp. after | |||
Concerns regards std::unordered_map itself -- it's not great. Should we look at other unorderd_map implementations? | |||
QMap => std::map, yes | |||
QLinkedList => Qt5LinkedList | |||
(Need to clarify what ends up in a Qt5Support library) | |||
Do we need to provide generic accessors for arbitrary containers, esp. in the light of ranges added to C++20? (And what about things like toSet, toList, etc.?) Concerns raised by starting including std headers all over the place. | |||
== QString, QStringView, QByteArray == | == QString, QStringView, QByteArray == | ||
| Line 13: | Line 32: | ||
== Codecs == | == Codecs == | ||
Legacy text codecs implementations in Qt are going to be dropped from Qt itself; anything but UTF- codecs will require 3rd party (ICU). | |||
== Threading == | == Threading == | ||
| Line 23: | Line 43: | ||
** [http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0169r0.html P0169R0 - regex with Unicode character types] | ** [http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0169r0.html P0169R0 - regex with Unicode character types] | ||
** [http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1844r0.html P1844R0 - Enhancement of regex] | ** [http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1844r0.html P1844R0 - Enhancement of regex] | ||
* | |||
Revision as of 08:23, 21 November 2019
Session notes.
Recap:
Calendaring & time
Containers
QList = QVector by default in Qt 6
s/QList/QVector/g before Qt 6 releaase to avoid merging nightmare
Not sure if to keep Qt5List. We need more evaluation about how much code breaks (e.g. when Creator, KDE port it)
QPair=std::pair => no brainer
QHash in terms of std::unordered_map: Lars, Peppe experimented on it, it "works", esp. after
Concerns regards std::unordered_map itself -- it's not great. Should we look at other unorderd_map implementations?
QMap => std::map, yes
QLinkedList => Qt5LinkedList
(Need to clarify what ends up in a Qt5Support library)
Do we need to provide generic accessors for arbitrary containers, esp. in the light of ranges added to C++20? (And what about things like toSet, toList, etc.?) Concerns raised by starting including std headers all over the place.
QString, QStringView, QByteArray
Split-up of QtCore
Codecs
Legacy text codecs implementations in Qt are going to be dropped from Qt itself; anything but UTF- codecs will require 3rd party (ICU).
Threading
- QRecursiveMutex split from QMutex
- QWaitCondition & QReadWriteCondition improvements?
- Future of QFuture