summaryrefslogtreecommitdiffstats
path: root/src/corelib/text/qstringalgorithms.h
Commit message (Collapse)AuthorAgeFilesLines
* QUtf8StringView: ensure binary compatibility throughout 6.xv6.1.0-rc1Thiago Macieira2021-04-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | We can't depend on whether the user compiles with -std=c++17 or -std=c++20. So select what we can depend on and make that permanent. Prior to this change: $ cat /tmp/test.cpp #include <QtCore/QUtf8StringView> void f(QUtf8StringView) {} $ qcd include $ g++ -S -o - -I. /tmp/test.cpp | grep globl | c++filt .globl f(QBasicUtf8StringView<false>) $ g++ -fPIC -std=c++20 -S -o - -I. /tmp/test.cpp | grep globl | c++filt .globl f(QBasicUtf8StringView<true>) After this change, they're both "false". QUtf8StringView should have been a concrete class that derived from QBsicUtf8StringView<whichever> and inherited all its constructors. We'd cause ODR violations in C++20, but nothing worse than what we usually do for BC reasons. That solution is too late for Qt 6.x. Let's revisit in 7.0. Pick-to: 6.1 dev Change-Id: I6bcbe88c072a438b8b4efffd166e77199ecb39e3 Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
* Mark places where we missed conversion to unicode character typesEdward Welbourne2021-01-081-1/+1
| | | | | | | | | | | We should use char32_t for the toUcs4() methods of QString and QStringView and use char16_t for QString::utf16(), thereby matching QStringView. These naturally imply knock-on changes in various places. Unfortunately, we didn't make those changes in Qt 6, so they'll have to wait for Qt 7. Change-Id: I18451d4b31b76658092e19d3fcbc8bc0fe5ce307 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* QStringView: add some QRegularExpression-related overloadsGiuseppe D'Angelo2020-12-101-0/+17
| | | | | | | | | [ChangeLog][QtCore][QStringView] Added the indexOf(), contains(), lastIndexOf() and count() methods taking a QRegularExpression. Fixes: QTBUG-89050 Change-Id: Ic726754f67e06b3764302d2fad252e0378a77afc Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Optimize equality operators for string classesLars Knoll2020-10-071-0/+10
| | | | | | | | | | | | | Using compare() for those operators is not a good idea, as we can't shortcut comparisons if the string sizes are different. This alone made our HTML parser in QtGui around 15% slower. Don't go through QAnyStringView to implement compare() for QUtf8StringView, use QtPrivate::compareStrings() directly instead. Task-number: QTBUG-86354 Change-Id: I04869c29c9918161990dc1baf8e943b3a264ff3c Reviewed-by: Karsten Heimrich <karsten.heimrich@qt.io>
* Replace Q_REQUIRED_RESULT with [[nodiscard]]Allan Sandfeld Jensen2020-09-251-53/+53
| | | | | | | It was already used many places directly making the code inconsistent. Change-Id: I3b14bc6c333640fb3ba33c71eba97e78c973e44b Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Remove deprecated APILars Knoll2020-09-151-2/+0
| | | | | | | And replace it's few remaining usages Change-Id: I2dfbbaa5259acfece028606bef1e872c5692f9fe Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Long live Q{Any,Utf8}StringView!Marc Mutz2020-08-311-1/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We need to add these two classes at the same time, because QAnyStringView makes all QUtf8StringView relational operators moot. We might want to add some later, esp. for UTF-8/UTf-8 comparisons, to avoid the pessimization that we can't early-out on size() mismatch in QAnyStringView equality operators, but that's an optimization, not a correctness issue, and can be fixed in a source-compatible way even after Qt 6 is released. To deal with the char8_t problem in C++20, make QUtf8StringView a class template out of which two UTF-8 views can be instantiated: the Qt 7 version, which depends on C++20 char8_t as value_type, and the Qt 6 version where value_type is a char. Use inline namespaces to map the QUtf8StringView identifier to one or the other, depending on the C++ version used to compile the user code. The inline namespace names must needs be a bit ugly, as their inline'ness depends on __cpp_char8_t. If we simply used q_v1/q_v2 we'd be blocking these names for Qt inline namespaces forever, because it's likely that inline'ness of other users of inline namespaces in Qt depends on things other than __cpp_char8_t. While inline'ness of namespaces is, theoretically speaking, a compile-time-only property, at least Clang warns about mixed use of inline on a given namespace, so we need to bite the bullet here. This is also the reason for the QT_BEGIN_..._NAMESPACE macros: GCC is ok with the first declaration making a namespace inline, while Clang warns upon re-opening an inline namespace as a non-inline one. [ChangeLog][QtCore][QUtf8StringView] New class. [ChangeLog][QtCore][QAnyStringView] New class. Change-Id: Ia7179760fca0e0b67d52f5accb0a62e389b17913 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Replace Qt CONSTEXPR defines with constexprAllan Sandfeld Jensen2020-08-141-1/+1
| | | | | | | | Both normal and relaxed constexpr are required by our new minimum of C++17. Change-Id: Ic028b88a2e7a6cb7d5925f3133b9d54859a81744 Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
* Implement UTF-16 to UTF-8 case-insensitive compare and make publicThiago Macieira2020-08-051-0/+1
| | | | | Change-Id: Ied637aece2a7427b8a2dfffd16116cf3645c6359 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Use QList instead of QVector in corelibJarek Kobus2020-06-251-1/+1
| | | | | | | | | | Applied to headers only. Source file to be changed separately. Omitted statemachine for now to avoid conflicts. Omitted qmetatype.h for now - to be handled later. Task-number: QTBUG-84469 Change-Id: I317376037a62467c313467d92955ad0b7473aa97 Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
* Move implementation of QVector/List back to qlist.hLars Knoll2020-06-201-2/+1
| | | | | | | | | | | | | And name the main class QList. That's also the one we document. This gives less porting pain for our users, and a lot less churn in our API, as we use QList in Qt 5 in 95% of our API. In addition, it gives more consistent naming with QStringList and QByteArrayList and disambiguates QList vs QVector(2|3|4)D. Fixes: QTBUG-84468 Change-Id: I3cba9d1d3179969d8bf9320b31be2230d021d1a9 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Add support for count() to QStringViewLars Knoll2020-05-301-0/+3
| | | | | | | Make the API more symmetric with regards to both QString and QStringRef. Change-Id: Ia67c53ba708f6c33874d1a127de8e2857ad9b5b8 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Port qustrlen and qustrchr to char16_tMarc Mutz2020-05-121-2/+2
| | | | | | | Fix callers. Change-Id: Iaf604c890941aa3de3bd31da300b2066e65968ed Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Introduce QString(View)::isValidUtf16Giuseppe D'Angelo2019-12-201-0/+1
| | | | | | | | | | | | | | | | | | | QString(View)s can be built or manipulated in ways that make them contain/refer to improperly encoded UTF-16 data. Problem is, we don't have public APIs to check whether a string contains valid UTF-16. This knowledge is precious if the string is to be fed in algorithms, regular expressions, etc. that expect validated input (e.g. QRegularExpression can be faster if it can assume valid UTF-16, otherwise it has to employ extra checks). Add a function that does the validation. [ChangeLog][QtCore][QStringView] Added QStringView::isValidUtf16. [ChangeLog][QtCore][QString] Added QString::isValidUtf16. Change-Id: Idd699183f6ec08013046c76c6a5a7c524b6c6fbc Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* qstringalgorithms.h: add pure, noexcept, constexprMarc Mutz2019-07-291-5/+6
| | | | | | | ... where they were missing. Change-Id: I58c32e57675b5d5ee500722933ef4a356a679e46 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Move text-related code out of corelib/tools/ to corelib/text/Edward Welbourne2019-07-101-0/+106
This includes byte array, string, char, unicode, locale, collation and regular expressions. Change-Id: I8b125fa52c8c513eb57a0f1298b91910e5a0d786 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-04-19 20:21:37 +0000