summaryrefslogtreecommitdiffstats
path: root/src/corelib/thread/qfuturewatcher_p.h
diff options
context:
space:
mode:
authorEdward Welbourne <edward.welbourne@qt.io>2021-07-19 16:22:30 +0200
committerQt Cherry-pick Bot <cherrypick_bot@qt-project.org>2021-07-22 17:08:03 +0000
commit715c0a746ac04b2638c1b004cec31cf08fe3a5e4 (patch)
tree61c035f7d5fc01e45e41eae7c4964ef177008fb7 /src/corelib/thread/qfuturewatcher_p.h
parenteda3910669a91165fe0f63ee660c759b214a959a (diff)
Use QChar::fromUcs4(i) rather than QChar(i) on out-of-range i
Follow-up to commit 915be6606ead25f4fbbbcb2687b33cf22a955177, catching some benchmarks that took for granted they can assign an arbitrary int to QChar. Since 6.0 this has triggered an assertion. Given the choice between limiting the range (from 100000 to 0x10000) and actually handling the out-of-range values as UCS-4 data, the latter seemed like a more interesting test. At the same time, take the construction of the strings out of the loop, as that's not a QMap performance matter, it's a QString one. Task-number: QTBUG-91713 Change-Id: Id6abab08b5c879f0f764350f66d6aa1dd9f1620a Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com> (cherry picked from commit b5950f6aff9ca646c55e640dd3d67105f56070e1) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Diffstat (limited to 'src/corelib/thread/qfuturewatcher_p.h')
0 files changed, 0 insertions, 0 deletions