Uploaded image for project: 'Qt'
  1. Qt
  2. QTBUG-81053

Upgrade remaining single-UTF16-codepoint members of QLocaleData

    XMLWordPrintable

Details

    • User Story
    • Resolution: Done
    • P2: Important
    • 6.0
    • None
    • Core: Locales (i18n)
    • All
    • 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

          No reviews matched the request. Check your Options in the drop-down menu of this sections header.

          Activity

            People

              Eddy Edward Welbourne
              Eddy Edward Welbourne
              Maurice Kalinowski Maurice Kalinowski
              Alex Blasche Alex Blasche
              Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Time Tracking

                  Estimated:
                  Original Estimate - 1 week Original Estimate - 1 week
                  1w
                  Remaining:
                  Remaining Estimate - 0 minutes
                  0m
                  Logged:
                  Time Spent - 1 week, 2 days
                  1w 2d

                  Gerrit Reviews