summaryrefslogtreecommitdiffstats
path: root/src/corelib/tools/qstringview.h
Commit message (Collapse)AuthorAgeFilesLines
* QStringView: add startsWith(), endsWith()Marc Mutz2017-04-281-0/+16
| | | | | Change-Id: I72aef9236daedc3013c62d3f1d737159f85572b8 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Disentangle string-related headersMarc Mutz2017-04-251-12/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It's starting to hinder QStringView development (QString::append(QStringView), e.g.). - qbytearray.h includes qstring.h, but is included by qstring.h -> remove qstring.h include from qbytearray.h - the QStringLiteral definition is used from both qstring.h and qstringview.h -> extract into its own header, move QStringViewLiteral definition there, too - the qCompareStrings(), qConvertTo*() functions are used by QString and QStringView -> also extract into own header, included from qstring.h and qstringview.h - QStringView::toString() depends on QString, which depends on QStringView -> move QStringView::toString() definition to qstring.h, after the definition of QString -> move qstringview.h up to all the other includes in qstring.h This is starting to look like a DAG again, and allows to remove the unholy #ifndef QSTRING_H # include <qstring.h> #endif hack from qstringview.h. [ChangeLog][Potentially Source-Incompatible Changes][QByteArray] qbytearray.h no longer includes qstring.h. In particular, this means that in order to use QStringBuilder with QByteArray, you need to include both qbytearray.h and qstring.h now (or <QByteArray> and <QString>, resp.). Change-Id: I7f8acf9c11bc1731266cd25c6eda9fb36723f364 Reviewed-by: Anton Kudryavtsev <antkudr@mail.ru> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* QStringView: mark as primitive typeMarc Mutz2017-04-211-1/+1
| | | | | | | | | | | | Every bit pattern of a QStringView is a Partially-Formed Object, and QStringViews are trivially copyable. That's what Q_PRIMITIVE_TYPE means, even if the docs are still talking about valid instead of partially-formed objects. Change-Id: I79d4f79fbab0ec2608620e88b6593e26686af304 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Anton Kudryavtsev <antkudr@mail.ru> Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Use new Q_STDLIB_UNICODE_STRINGS and Q_COMPILER_UNICODE_STRINGSMarc Mutz2017-04-201-1/+1
| | | | | | | | | ... instead of the combination with Q_OS_WIN we used so far. This patch adapts ocurrences that are new in 5.10. Change-Id: If392df481713e56c776c2326e0e02324a3a80c89 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QStringView: fix position of Q_REQUIRED_RESULT macrosMarc Mutz2017-04-201-32/+32
| | | | | | | | ... to be compatible with the C++17 [[nodiscard]]. Change-Id: I60fb9b9077e8c59a03a212c73d4e6c814cc0357d Reviewed-by: Anton Kudryavtsev <antkudr@mail.ru> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QStringView: add internal qToStringViewIgnoringNull()Marc Mutz2017-04-191-0/+6
| | | | | | | | | | | | | | | | | | As long as a null QString still returns non-null data(), QStringView's QString constructor needs to call isNull(). That's a branch we often can do without, so add an internal function that bypasses this correctness check. It's internal, since we might have a Q6String that returns nullptr data() when null, which will remove the need for this function. What the QStringView(QString) ctor does will also have to be re-evaluated come Qt 6, but for now, keep the public QString- QStringView conversion correct. Change-Id: I35dc7383bc3bd018f46aeec429185135a38ddcef Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* QStringView: plaster API with Q_REQUIRED_RESULTMarc Mutz2017-04-181-27/+27
| | | | | | | | There's no reason to use it only on some functions with return values and not others. Change-Id: If50a669f49e9e2f71173dea94465a5de58a7783e Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* QStringView: add chopped(), chop(), and truncate()Marc Mutz2017-04-181-0/+7
| | | | | | Change-Id: I33925f5b2b3e0904f47f18f3cbab480d7f844734 Reviewed-by: Anton Kudryavtsev <antkudr@mail.ru> Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Make QStringView::storage_type publicMarc Mutz2017-04-101-1/+1
| | | | | | | | ... so users of QStringView::utf16() can use it, without having to revert to decltype()/auto. Change-Id: Ie09696b9354d3917914f8e2692769cfd35b01ae1 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* Add qConvertTo{Utf8,Latin1,Local8Bit,Ucs4}() and corresponding QStringView ↵Marc Mutz2017-04-071-0/+4
| | | | | | | | | | | | | | | | | methods Like the qt_compare_strings()/qCompareStrings() split, distinguish between the internal and exported functions. Because of the circular dependency between qstring.h and qvector.h, the inline toUcs4() function has to be in qvector.h. At some point, we need to refactor the headers so qvector.h is lower in the dependency chain than qstring.h. It's not the first time this bites. Change-Id: Ief9f3bd92c83cdd1f31c51c700f42e146916eefd Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QStringView: fix ambiguity between f(QString)/f(QStringView) with ↵Marc Mutz2017-04-061-4/+0
| | | | | | | | | | | | | | | | | QString::null args ... by removing the QStringView(QString::Null) ctor. This means that QStringView(QString::null) will now fail to compile. That's ok, since we've deprecated QString::null in the last Qt version. This will also help pulling up the QStringView definition to before the QString one in qstring.h, something that we'll require for properly adding QStringView-append/prepend/insert to QString. Change-Id: I3c836732be1e185111b13950be9d8dcd935734ff Reviewed-by: Anton Kudryavtsev <antkudr@mail.ru> Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* QStringView: use qssize_t as size_typeMarc Mutz2017-04-061-18/+19
| | | | | | | | | | Nothing changes, we've just given 'QIntegerForSizeof<size_t>::Signed' a better name in qglobal.h and now use it in QStringView API and users. Change-Id: Ibea1ae26e95b3a96708400fd4b0cd120459d57b6 Reviewed-by: Anton Kudryavtsev <antkudr@mail.ru> Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
* QStringView: add an array ctorMarc Mutz2017-04-041-6/+47
| | | | | | | | | With sufficient enable_if magic, the array ctor can overload the pointer ctor and statically determine the size of the array passed. Consequently, remove the sizeof in QStringViewLiteral again. Change-Id: I486baa3cafefde60ccc5f2b47eb94ee53cefe63c Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* QStringView: add mid(), left(), right()Marc Mutz2017-03-311-0/+9
| | | | | | | | Change-Id: If1d2cf175d51b3c02881e21937b0a2d33b78aadd Reviewed-by: Anton Kudryavtsev <antkudr@mail.ru> Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* QStringView: improve manual overload managementMarc Mutz2017-03-291-17/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We want to prevent QStringView(QChar|QLatin1String|QByteArray|const char*) from compiling as QStringView(QString(...)), so I added = delete'ed ctors for these types to QStringView. However, that makes QStringView participate in overload resolution for these types. Even if the QStringView ctor will always fail to compile, the presence of these ctors alone makes calls to functions overloaded on QString and QStringView ambiguous: f(QStringView); f(QString); f(foo); // ambiguous f(QChar('f')) // ambiguous f(QLatin1String(foo)); // ambiguous f(QByteArray(foo)); // ambiguous Fix by making the QString and QStringRef constructors templates constrained to accept only these two types. This should also help to move the QStringView definition to before the QString one (as soon as we get rid of or start to ignore QString::Null), simplifying a lot of code in qstring.h down the line. This should also fix MSVC's accepting of two user-defined conversions which caused static non-compile-tests to fail in the initial QStringView patch, and which were therefore removed. This patch brings them back. Change-Id: I95ac38c0d31cd8c726f7e952017569d32e484413 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Long live QStringView!Marc Mutz2017-03-241-0/+226
QStringView is a simple container for (const QChar*, int) and (const char16_t*, size_t). It acts as a replacement interface type for const QString and const QStringRef, and enables passing all kinds of string-like types to functions otherwise expecting const QString& - without the need to convert to QString first. The use of this new class is guarded by a macro that enables three levels of QStringView support: 1. offer QStringView, overload some functions taking QString with QStringView 2. like 1, but remove all overloads of functions taking QStringRef, leaving only the function taking QStringView. Do this only where QStringRef overloads tradionally existed. 3. like 2, but replace functions taking QString, too. This is done in order to measure the impact of QStringView on code size and execution speed, and to help guide the decision of which level to choose for Qt 6. This first patch adds QStringView with most of its planned constructors, but not much more than iterators and isNull()/isEmpty(). Further patches will add support for QStringView to QStringBuilder, add QStringView overloads of functions taking QString, and add the complete API of const QString to QStringView. [ChangeLog][QtCore][QStringView] New class, superseding const QString and QStringRef as function parameters, accepting a wide variety of UTF-16 string data sources, e.g. u"string", std::u16string{,_view}, and, on Windows, L"string", std::wstring{,_view} without converting to QString first. Change-Id: Iac273e46b2c61ec2c31b3dacebb29500599d6898 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>