Details
-
Task
-
Resolution: Done
-
P3: Somewhat important
-
None
-
None
-
5
-
4cf299eb5b (qt/qtbase/dev) 4cf299eb5b (qt/tqtc-qtbase/dev)
-
Team Two Foundation Sprint 52, Team B Foundation Sprint 53
Description
Almost no backend stores the keys in UTF-16 (Windows, maybe?), and even then, they don't do so using QString. So using QStrings as keys is quite counter-productive, because the typical ASCII key first gets converted to UTF-16 on the heap, then back to ASCII (or a superset thereof) for persisting. A QAnyStringView as the key type can thus a) avoid re-coding the charsets and b) compactify the calling code, as usual, by not having to construct and destruct a QString.
This task is just about the user-facing API. The natural follow-up task is to remove the UTF-16 middle-man and convert the QAnyStringView to the backend's native encoding directly, but that likely requires QAnyString.
Attachments
Issue Links
- is required for
-
QTBUG-101392 Port QSettings' backends to native keys
- Open
For Gerrit Dashboard: QTBUG-101390 | ||||||
---|---|---|---|---|---|---|
# | Subject | Branch | Project | Status | CR | V |
353688,7 | QSettings: port API from QString to QAnyStringView keys | dev | qt/qtbase | Status: MERGED | +2 | 0 |