summaryrefslogtreecommitdiffstats
path: root/src/corelib/text/qutf8stringview.h
Commit message (Collapse)AuthorAgeFilesLines
* Add isValidUtf8() methods to QUtf8StringView and QByteArray{,View}Ievgenii Meshcheriakov2021-09-221-0/+5
| | | | | | | | | | | | | | | The new methods return true if the string contains valid UTF-8 encoded data, or false otherwise. [ChangeLog][QtCore][QByteArray] Added isValidUtf8() method. [ChangeLog][QtCore][QByteArrayView] Added isValidUtf8() method. [ChangeLog][QtCore][QUtf8StringView] Added isValidUtf8() method. Task-number: QTBUG-92021 Change-Id: I5d0cb613265d98b1f189c5f5cc09c1f7db302272 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* Fix coding-style violation in QUtf8StringView::operator==()Edward Welbourne2021-06-231-3/+3
| | | | | | | Task-number: QTBUG-94407 Pick-to: 6.2 Change-Id: I00a9c14963fe8f8d1b524350aec5544ff5dd609c Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QUtf8StringView: ensure binary compatibility throughout 6.xThiago Macieira2021-04-201-0/+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. Change-Id: I6bcbe88c072a438b8b4efffd166e77199ecb39e3 Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io> (cherry picked from commit c7deb3400faa1d9389137fe63ffbffade8203850) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Q{*String,ByteArray}View::length(): use qsizetype, not intGiuseppe D'Angelo2021-04-151-6/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Looks like these ones have been forgotten in the Qt 5 -> 6 upgrade to qsizetype. Change them to return qsizetype as well, and fix the docs. Being entirely inline, non-exported classes, we should be able to get away with it without affecting binary compatibility. Moreover, there's no reason for keeping them deprecated. Requires some minor adjustments, just like the ones done for size()'s changes. [ChangeLog][QtCore][QStringView] The length() function now returns `qsizetype`, not `int`, for consistency with the other string and container classes in Qt. Following this change, it has been un-deprecated. [ChangeLog][QtCore][QAnyStringView] The length() function now returns `qsizetype`, not `int`, for consistency with the other string and container classes in Qt. Following this change, it has been un-deprecated. [ChangeLog][QtCore][QUtf8StringView] The length() function now returns `qsizetype`, not `int`, for consistency with the other string and container classes in Qt. Following this change, it has been un-deprecated. [ChangeLog][QtCore][QByteArrayView] The length() function now returns `qsizetype`, not `int`, for consistency with the other string and container classes in Qt. Following this change, it has been un-deprecated. Fixes: QTBUG-92496 Change-Id: Ie0f4939d1083884e95d4725f891b6c6764532cb8 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QUtf8StringView: Check size directly in operator==Fabian Kosmale2021-03-211-1/+2
| | | | | | | | | We can avoid the non-inlined function call if the sizes do not match up. This aligns the implementation of QUtf8StringView's operator== with the one used for the other string classes. Change-Id: Iaaf71b236edc0385551639961f753f11b324b327 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Doc: Add a workaround for QUtf8StringView's missing docsTopi Reinio2020-11-061-1/+14
| | | | | | | | | | | | QUtf8StringView is a specialization of QBasicUtf8StringView but we only want to document the former. Add a workaround when Q_CLANG_QDOC is defined to rename the base type, so the documentation in the .qdoc file is matched correctly. Fixes: QTBUG-88030 Task-number: QTBUG-86295 Change-Id: Id6e3d6fd5c28603bebf30771b7a47c3f76ca709d Reviewed-by: Paul Wicking <paul.wicking@qt.io>
* Optimize equality operators for string classesLars Knoll2020-10-071-3/+9
| | | | | | | | | | | | | 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>
* Make QAnyStringView comparison operators hidden friendsKarsten Heimrich2020-10-061-0/+23
| | | | | | | | | | Also add the very same operators to the QBasicUtf8StringView class to overcome the compiler issues seen on gcc. Fixes: QTBUG-86481 Change-Id: I12484455ebd3b7b38d4ad67c38977d76f9b3ddfa Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Q(Any|Utf8)StringView: move array size deduction feature to fromArrayMÃ¥rten Nordheim2020-09-181-2/+8
| | | | | | | | | | | | | The constructor taking an array literal will now stop at the first null-terminator encountered. And fromArray is introduced which only supports array literals. Constructs a view of the full size. Explicit so it shouldn't be surprising. Change-Id: I1497c33a5c12453a95e87c990abe6335b2817081 Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Long live Q{Any,Utf8}StringView!Marc Mutz2020-08-311-0/+329
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>