Details
-
User Story
-
Resolution: Done
-
P2: Important
-
None
-
-
21
-
Qt6_Foundation_ Sprint 1, Qt6_Foundation_ Sprint 2, Qt6_Foundation_ Sprint 3
Description
QLocaleData has many data fields encoded as a pair m_name_idx, m_name_size of (usually quint16, but a few are quint8) members indicating the start-index and size of the data in one of the various large arrays we generate from the CLDR data. This allows the data field to represent an arbitrary string.
A few of the data fields are encoded as plain char16_t members: the digits and number formatting fragments; and the quote starts and ends. Some number systems in CLDR have digits outside the basic plane, that have to be represented as surrogate pairs, so we're presently unable to represent those number systems, which obliges us to omit several locales from the data we could be extracting from CLDR. These single-char16_t members should be replaced, like the other data fields, with index-and-size data, so that we can consistently represent all locales in CLDR.
In the process (subject to a review of the maximum m_*_size member among all data fields and locales) it seems likely that we can standardise the index-and-size data to use quint8 for all the size members. Given padding constraints, this would require separating the size members from the index members in the struct, requiring some care in the code that generates the data from CLDR; however, it would free up 23 bytes, of which the newly index-and-size fields would only take up 12, so QLocaleData may actually shrink. Some index members can probably also be made quint8 if we take care to put always-small fields early in the structure, so that their offsets from its start are < 256.
There are various methods in QLocale that return a simple QChar but should be converted to return QString (as noted in a ### Qt 5 comment already present against these methods): decimalPoint(), groupSeparator(), percent(), zeroDigit(), negativeSign(), positiveSign(), exponential(). These require either an API break (source incompatible) or new methods with suboptimal names. Changing the return type will cause compile-time breakage, which should at least be immediately visible, but those who need to support Qt5 and Qt6 in parallel shall need #if-ery round affected code.
Matching methods of QLocalePrivate have the same problem (and we can simply change their return type).
A few methods of QLocaleData take QChar parameters that shall likewise need to become QString.
Attachments
Issue Links
- depends on
-
QTBUG-81905 macOS 10.14 binds to low port numbers: tests expected that to fail
- Closed
- is required for
-
QTBUG-69324 QLocale can't represent outer plane characters
- Closed
-
QTBUG-81050 Do number-formatting correctly
- Closed
- relates to
-
QTBUG-79902 QLocale: make fuller and more faithful use of the CLDR data
- Open