That requires including qcontainerfwd.h to the headers, so that
we could get access to QtPrivate::MaxAllocSize.
The max_size() methods are added for compatibility with stl.
The logic for most of the views is similar. The only exception is
QAnyStringView, because its character size may vary, depending on the
contained data.
The maxSize() methods are the static equivalents of max_size().
QASV does not have it for the reasons mentioned above.
[ChangeLog][QtCore] Added max_size() to all string-view types.
Amends 7ce6920aac.
Found in 6.8 API review.
Change-Id: I467c7d64ec3d92eb424eb5b94a39ec3d45d63d1f
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
(cherry picked from commit 2382bfb5b03f6f03a31981dc416121cf556b962a)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Methods with preconditions can't be noexcept (from Marc in code
review).
[ChangeLog][QtCore][String Views] Added slice() methods to
Q{String,ByteArray,Latin1String,Utf8String,AnyString}View which work
like sliced() but modify the view they are called on.
Found in API review.
Task-number: QTBUG-99218
Change-Id: Ic8ef3085f7cfac86b8404fb28d491ca38ad121eb
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
(cherry picked from commit 8f68bd9e6353a42d3b71d893b27fec6bedced501)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Replace the friend relational operators for QSV vs QSV and QSV vs QChar
comparison.
Task-number: QTBUG-117661
Change-Id: I547f69dac67c27b04864e56b383e75e213a17bfe
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Also update the QCollator::compare() docs for consistency.
Task-number: QTBUG-114822
Change-Id: I5fca896cacedd93ce5a4a1a8aead1986a21f6993
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
When QDoc parses a project, it parses the source code to extract the
user-provided documentation and perform sanity checkings based on the
code itself on it.
When QDoc parses an "\fn" command as part of this process, it tries to
understand, based on its intermediate representation built on the
information extracted from the code-base, which "documentable element"
the "\fn" refers to.
When QDoc performs this "matching" process, it takes into consideration
only a certain amount of information.
For example, no checking is performed over the template declaration of a
callable.
Due to some upcoming documentation, where two callables are
indistinguishable to the current process, as they differ only in their
template declaration, QDoc will start to take into consideration the
template declaration of a callable when matching.
This implies that an "\fn" command should now provide information
parity, with regards to template declaration for callables, with the
code-base so that QDoc can perform the match correctly.
The documentation for of the members of `QStringView` is not in sync
with the intended target template declaration.
Hence, add the missing information to the relevant "\fn" commands.
Task-number: QTBUG-118080
Change-Id: Ia5c6f99d38b0080b150cbfca83ae605cc07d9b72
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
In C++20 std::basic_string_view has gained a range constructor (like
QStringView always had), but that range constructor has been made
explicit. This means we can't just pass a QString(View) to a function
taking a u16string_view. The consensus seems to be that that types that
should implictly convert towards stdlib's string views should do that
via implicit conversion operators. This patch adds them for
* QByteArrayView => std::string_view
* QString(View) => std::u16string_view
* QUtf8StringView => std::string_view or std::u8string_view, depending
on the storage_type
QLatin1StringView doesn't have a matching std:: view so I'm not enabling
its conversion.
QByteArray poses a challenge, in that it already defines a conversion
towards const char *. (One can disable that conversion with a macro.)
That conversion makes it impossible to support:
QByteArray ba;
std::string_view sv1(ba); // 1
std::string_view sv2 = ba; // 2
because:
* if only operator const char *() is defined, then (2) doesn't work
(situation right now);
* if both conversions to const char * and string_view are defined, then
(1) is ambiguous on certain compilers (MSVC, QCC). Interestingly
enough, not on GCC/Clang, but only in C++17 and later modes.
I can't kill the conversion towards const char * (API break, and we use
it *everywhere* in Qt), hence, QByteArray does not get the implicit
conversion, at least not in this patch.
[ChangeLog][QtCore][QByteArrayView] Added an implicit conversion
operator towards std::string_view.
[ChangeLog][QtCore][QString] Added an implicit conversion operator
towards std::u16string_view.
[ChangeLog][QtCore][QStringView] Added an implicit conversion operator
towards std::u16string_view.
[ChangeLog][QtCore][QUtf8StringView] Added an implicit conversion
operator towards std::string_view (QUtf8StringView is using char
as its storage type in Qt 6). Note that QUtf8StringView is planned to
use char8_t in Qt 7, therefore it is expected that the conversion will
change towards std::u8string_view in Qt 7.
Change-Id: I6d3b64d211a386241ae157765cd1b03f531f909a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Code points is what you get when surrogate pairs have been joined
Pick-to: 6.6 6.5 6.2
Change-Id: I86c4131de5782ce1e6342217947a603ca16bb521
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
For QAnyStringView, the docs were missing completely.
For QUtf8StringView and QStringView, they weren't updated following
the rewrite of the std::basic_string ctors into generic Container
ones.
Amends 9e1dc1e8a9 and
2c9529e158.
Pick-to: 6.5 6.2
Task-number: QTBUG-112746
Change-Id: I6eef2294db01e35f1a085df7fc76c25c6003530d
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Templates have different overload characteristics from normal
functions, and treating q_no_char8_t and q_has_char8_t::QUtf8StingView
separately is never necessary, as one implicitly converts into the
other.
Add docs for the new UTF-8 compare() functions.
Amends b977ae371a.
Found in API review.
Pick-to: 6.5 6.5.0
Change-Id: I58b4b28a3eccde1976d71cfa3412b734d46f314d
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Unify wording as "{Latin-1,UTF-16} string viewed by \a str".
Drive-by change: Fix a grammatical error, it's "a US-ASCII", not an
(because it's pronounced by the letter name "U" which is pronounced
like "you", so "a" not "an").
Task-number: QTBUG-108711
Pick-to: 6.5
Change-Id: Iff763f4008341c35317bb3d7a2a228767ff6a648
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
For the constructors, replace int with qsizetype. For the incorrect
return type in \fn of length(), drop the return type, the presence of
which violated DRY, stressing the importance of that SOLID principle.
Fixes: QTBUG-103531
Pick-to: 6.4 6.3 6.2
Change-Id: Ic7a8e1953333c28a2722fd7f753a0b5af6777395
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It was required back in Qt 5 times, so that we could use
qvariant_cast<> or QVariant.value() on it. Not required in Qt 6
anymore.
As a drive-by: cleanup some unneeded includes in qstringview.cpp
Task-number: QTBUG-102350
Pick-to: 6.4
Change-Id: Idbcdc5cfe62cf4a55b86e227106d7a997997e0ba
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Replace the current license disclaimer in files by
a SPDX-License-Identifier.
Files that have to be modified by hand are modified.
License files are organized under LICENSES directory.
Task-number: QTBUG-67283
Change-Id: Id880c92784c40f3bbde861c0d93f58151c18b9f1
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Both QByteArray and QString can contain more than 2^32 elements on 64
bits platforms, so the warning does not apply any more.
Change-Id: I4604c1fe225922a0df7e78135eeb5a1e2b84fea3
Pick-to: 6.2 6.3
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
- Replaced QLatin1String with QLatin1StringView in QString/QLatin1String
APIs and docs (except for QLatin1String class declaration and ctor
names).
- Made the docs look like QLatin1StringView is "The Real Thing".
[ChangeLog][QtCore] Made QLatin1StringView the recommended name for
referring to a Latin-1 string view (instead of QLatin1String).
Task-number: QTBUG-98434
Change-Id: I6d9a85cc956c6da0c910ad7d23be7956e4bd94ac
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
QString already has a localeAwareCompare(QStringView, QStringView)
static method. Use it in QStringView::localeAwareCompare(QStringView).
[ChangeLog][QtCore][QStringView] Added
QStringView::localeAwareCompare().
Task-number: QTBUG-98431
Change-Id: Iec3865a5439d9fb653cc1150da21042186bdee98
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Required for the API symmetry between QStringView and QLatin1String.
[ChangeLog][QtCore][QStringView] Added an overload of
QStringView::count() for QLatin1String.
Change-Id: Ic49a4b31e8f6f0969eff0f792654d23a60e06c49
Task-numer: QTBUG-98431
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Commit 6cee204d56 introduced overloads
of lastIndexOf() which drop the 'from' argument, inadvertently fixing
QTBUG-80694, but failed to provide the new overloads for all existing
lastIndexOf() overloads, making the fix for QTBUG-80694 incomplete.
This patch completes the fix, by adding the missing overloads (for
char-likes) and also adds the missing (non-regex) tests to
tst_qstringapisymmetry.
Also amends 1c164ec7f2.
Fixes: QTBUG-80694
Change-Id: Ib4b3d597d658ce2edf01a2bce0d711ecea593d6e
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* name method parameters consistently with their declaration
* don't document parameters that are not there
Pick-to: 6.2
Change-Id: I06ae9fdca357ed29eb7a72802f149eb4914181f4
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
When trying to fix 0-length matches at the end of a QString,
be83ff65c4 actually introduced a
regression due to how lastIndexOf interprets its `from` parameter.
The "established" (=legacy) interpretation of a negative `from` is that
it is supposed to indicate that we want the last match at offset `from +
size()`. With the default from of -1, that means we want a match
starting at most at position `size() - 1` inclusive, i.e. *at* the last
position in the string. The aforementioned commit changed that, by
allowing a match at position `size()` instead, and this behavioral
change broke code.
The problem the commit tried to fix was that empty matches *are* allowed
to happen at position size(): the last match of regexp // inside the
string "test" is indeed at position 4 (the regexp matches 5 times).
Changing the meaning of negative from to include that last position (in
general: to include position `from+size()+1` as the last valid matching
position, in case of a negative `from`) has unfortunately broken client
code. Therefore, we need to revert it. This patch does that, adapting
the tests as necessary (drive-by: a broken #undef is removed).
Reverting the patch however is not sufficient. What we are facing here
is an historical API mistake that forces the default `from` (-1) to
*skip* the truly last possible match; the mistake is that thre is simply
no way to pass a negative `from` and obtain that match. This means that
the revert will now cause code like this:
str.lastIndexOf(QRE("")); // `from` defaulted to -1
NOT to return str.size(), which is counter-intuitive and wrong. Other
APIs expose this inconsistency: for instance, using
QRegularExpressionIterator would actually yield a last match at position
str.size(). Similarly, using QString::count would return `str.size()+1`.
Note that, in general, it's still possible for clients to call
str.lastIndexOf(~~~, str.size())
to get the "truly last" match.
This patch also tries to fix this case ("have our cake and eat it").
First and foremost, a couple of bugs in QByteArray and QString code are
fixed (when dealing with 0-length needles).
Second, a lastIndexOf overload is added. One overload is the "legacy"
one, that will honor the pre-existing semantics of negative `from`. The
new overload does NOT take a `from` parameter at all, and will actually
match from the truly end (by simply calling `lastIndexOf(~~~, size())`
internally).
These overloads are offered for all the existing lastIndexOf()
overloads, not only the ones taking QRE.
This means that code simply using `lastIndexOf` without any `from`
parameter get the "correct" behavior for 0-length matches, and code that
specifies one gets the legacy behavior. Matches of length > 0 are not
affected anyways, as they can't match at position size().
[ChangeLog][Important Behavior Changes] A regression in the behavior of
the lastIndexOf() function on text-related containers and views
(QString, QStringView, QByteArray, QByteArrayView, QLatin1String) has
been fixed, and the behavior made consistent and more in line with
user expectations. When lastIndexOf() is invoked with a negative `from`
position, the last match has now to start at the last character in the
container/view (before, it was at the position *past* the last
character). This makes a difference when using lastIndexOf() with a
needle that has 0 length (for instance an empty string, a regular
expression that can match 0 characters, and so on); any other case is
unaffected. To retrieve the "truly last" match, one can pass a
positive `from` offset to lastIndexOf() (basically, pass `size()` as the
`from` parameter). To make calls such as `text.lastIndexOf(~~~);`, that
do not pass any `from` parameter, behave properly, a new lastIndexOf()
overload has been added to all the text containers/views. This overload
does not take a `from` parameter at all, and will search starting from
one character past the end of the text, therefore returning a correct
result when used with needles that may yield 0-length matches. Client
code may need to be recompiled in order to use this new overload.
Conversely, client code that needs to skip the "truly last" match now
needs to pass -1 as the `from` parameter instead of relying on the
default.
Change-Id: I5e92bdcf1a57c2c3cca97b6adccf0883d00a92e5
Fixes: QTBUG-94215
Pick-to: 6.2
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
- Fixed various texts in docs for QStringView, QUtf8StringView and
QAnyStringView copied from QString, that are still talking about string
or string reference instead of string view.
- Replaced 'string-view' with 'string view', which is the more commonly
used form.
- Fixed the wrong usage of uppercase 'If' in some places.
- Did minor adjusments, to make the docs consistent with docs of
QByteArray/QByteArrayView.
Change-Id: Ifb905e00957e869a8befad5a36d6b00b6e621a04
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
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>
Fix prototype of template member function, and fix see-also reference.
Change-Id: Ibb39925063dfeb3fd511f47a1606a0b243d4c2ef
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
Use correct member function prototype, which requires the template declaration.
Remove see-alsos that don't exist.
Document parameters for qTokenize.
Still lots of warnings from QStringTokenizer, due to the inheritance structure
of that template class and the declarations of nested types in undocumented
base classes.
Also, qdoc doesn't seem to recognize training this-lvalue/this-rvalue
declarations for overloads, and considers the second toContainer documentations
to override the first.
Change-Id: Iadf967d3328ddda52b6f66786836853bddeda79b
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
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>
Export some private functions from QUtf8 to resolve
undefined symbols in Qt5Compat after moving QStringRef.
Task-number: QTBUG-84437
Change-Id: I9046dcb14ed520d8868a511d79da6e721e26f72b
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
After API discussions, agreement was that from(n) is a bad name
for the method. Let's go with sliced(n) instead.
Change-Id: I0338cc150148a5008c3ee72bd8fda96fb93e9c35
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Omitting state machine and docs for now.
Task-number: QTBUG-84469
Change-Id: Ibfa5e7035515773461f6cdbff35299315ef65737
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
The recently-added slice() method has the problem that it's a noun
as well as a verb in the imperative. Like std::vector::empty, which
is both an adjective and a verb in the imperative, this may cause
confusion as to what the function does. Using the passive voice form
of slice(), sliced(), removes the confusion. While it can be read as
an adjective, too, that doesn't change the meaning compared to the
verb form.
Change-Id: If0aa01acb6cf5dd5eafa8226e3ea7f7a0c9da4f1
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
QString and QStringRef did bounds checking for left/right/mid, whereas
QStringView was asserting on out of bounds.
Relax the behavior for QStringView and do bounds checking on pos/n
as well. This removes a source of potentially hidden errors when porting
from QStringRef (or QString) to QStringView.
Unfortunately, one difference remains, where QByteArray::left/right()
behaves differently (and somewhat more sane) than QString and
QStringRef. We're keeping the difference here, as it has been around
for many years.
Mark left/right/mid as obsolete and to be replaced with the new
first/last/slice methods.
Change-Id: I18c203799ba78c928a4610a6038089f27696c22e
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
These methods are scheduled as a replacement for left/right/mid()
in Qt 6 with a consistent, narrow contract that does not allow
out of bounds indices, and therefore does permit faster
implementations.
Change-Id: Iabf22e8d4f3fef3c5e69a17f103e6cddebe420b1
Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This is a folllow-up to commits
548513a4bd and
a9aa206b7b, renaming the snippets files
referenced by the files moved out of corelib/tools/ to match the new
locations of the files using them.
Change-Id: I59f5d3c217ef835e9244387cc769e7212de9d8f5
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
This is doing the same as data(), but the method is widely being used in
Qt (e.g. in QString), so this will make it easier to change the type of a
variable from QString(Ref) to QStringView in a source compatible way.
Change-Id: Ic49bef688d3ce3c550336edf90130aa5cac8b497
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Make the API more symmetric with regards to both QString and QStringRef.
Change-Id: Ia67c53ba708f6c33874d1a127de8e2857ad9b5b8
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Make the API more symmetric with regards to both QString and QStringRef.
Having this available helps making QStringView more of a drop-in
replacement for QStringRef. QStringRef is planned to get removed in Qt 6.
Change-Id: Ife036c0b55970078f42e1335442ff9ee5f4a2f0d
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Ahmad Samir
Ivan Solovev
Luca Di Sera
Jaishree Vyas
Anton Kudryavtsev
Giuseppe D'Angelo
Mårten Nordheim
Marc Mutz
Lucie Gérard
Sona Kurazyan
Volker Hilsheimer
Paul Wicking
Thiago Macieira
Anton Kudryavtsev
Topi Reinio
Karsten Heimrich
Linus Jahn
Lars Knoll
Jarek Kobus
Marc Mutz
Edward Welbourne