Qt Contributor Summit 2019 - QtCore: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
No edit summary |
||
| Line 7: | Line 7: | ||
== Containers == | == Containers == | ||
QList = QVector by default in Qt 6 | * QList = QVector by default in Qt 6 | ||
* s/QList/QVector/g before Qt 6 releaase to avoid merging nightmare | |||
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 | |||
Not sure if to keep Qt5List. We need more evaluation about how much code breaks (e.g. when Creator, KDE port it) | * 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 in terms of performance (or: it's "as bad" as QHash, so the only save is the maintenance). Should we look at other unorderd_map implementations under BSD? What about qHash and the seeding? | |||
QPair=std::pair => no brainer | * QMap => std::map, yes | ||
* QLinkedList => Qt5LinkedList | |||
QHash in terms of std::unordered_map: Lars, Peppe experimented on it, it "works", esp. after | * (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. | |||
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 == | ||
== Split-up of QtCore == | == Split-up of QtCore == | ||
* | |||
== Codecs == | == Codecs == | ||
| Line 38: | Line 30: | ||
* QWaitCondition & QReadWriteCondition improvements? | * QWaitCondition & QReadWriteCondition improvements? | ||
* Future of QFuture | * Future of QFuture | ||
== Paths/Filesystem == | |||
* If you know about Windows path handling: please help Eddy! (E.g. filesystem paths that are neither absolute or relative) | |||
* Discuss if we want a dedicated filesystem path class -- we need to evaluate the impact on our API. | |||
** We want overloads taking std::fs::path, but not sure about a dedicated class to store paths | |||
== Other == | == Other == | ||
| Line 43: | Line 40: | ||
** [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] | ||
* | *Ville: performance concerns, std::regex implementations are still bad | ||
*We can stick with QRegularExpression, but that poses a buildsystem question (getting rid of bootstrap). CMake may fix it. So far only a couple of bootsrapped tools will actually require it. | |||
Revision as of 08:31, 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 in terms of performance (or: it's "as bad" as QHash, so the only save is the maintenance). Should we look at other unorderd_map implementations under BSD? What about qHash and the seeding?
- 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
Paths/Filesystem
- If you know about Windows path handling: please help Eddy! (E.g. filesystem paths that are neither absolute or relative)
- Discuss if we want a dedicated filesystem path class -- we need to evaluate the impact on our API.
- We want overloads taking std::fs::path, but not sure about a dedicated class to store paths
Other
- Regexp
- Ville: performance concerns, std::regex implementations are still bad
- We can stick with QRegularExpression, but that poses a buildsystem question (getting rid of bootstrap). CMake may fix it. So far only a couple of bootsrapped tools will actually require it.