summaryrefslogtreecommitdiffstats
path: root/src/corelib/text/qanystringview.h
Commit message (Collapse)AuthorAgeFilesLines
* Build fixes for GCC 11Ville Voutilainen2021-01-191-0/+1
| | | | | | | Task-number: QTBUG-89977 Change-Id: Ic1b7ddbffb8a0a00f8c621d09a868f1d94a52c21 Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Fix QAnyStringView comparison documentationVolker Hilsheimer2020-11-091-1/+1
| | | | | | | | | | qdoc's clang knows about spaceship operator, but we still need to document the regular ones. Also add missing return types. Change-Id: If382ac2f51a49c9adbe4a99025403a3e8332fabd Reviewed-by: Paul Wicking <paul.wicking@qt.io>
* Optimize equality operators for string classesLars Knoll2020-10-071-2/+3
| | | | | | | | | | | | | 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-20/+24
| | | | | | | | | | 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/+292
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>