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>
- QCborError: Classes cannot relate to header files; use \inheaderfile
instead and link to the class from header file documentation.
- QRecursiveMutex: QDoc doesn't allow shared documentation comments
for duplicating \fn docs between the base and deriving classes.
Remove the sharing, the function documentation is available under
'All Members' doc for QRecursiveMutex.
- QMultiMap: unite() and one overload of insert() were not recognized
because their definitions in the same header file interfered with
QDoc - use Q_CLANG_QDOC macro to comment them out, and tag \fn
comments to ensure that the function documentation is matched.
Change-Id: Ic96869904a72d92453e4ffa6901000147571969b
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
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>
Now that all supported compilers support char16_t, we don't need the
storage_type == wchar_t hack for MSVC anymore.
Remove it. Adapt docs.
Change-Id: I55df6c8a9fa5a9c7e6f53ba89f3850956b369061
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
Amends e89fbd8c3a.
- While QString::data() never returns nullptr, QStringView::data()
may, which makes calling QStringView{}.toWCharArray() UB on Windows
(since memcpy's 2nd argument must never be nullptr, even if the size
is zero). Fix by protecting the memcpy call.
- QStringView, by design, does not use out-of-line member functions,
because calling these forces the QStringView object onto the stack.
Fix by making inline.
Also use the more efficient qToStringViewIgnoringNull(), as the result
does not depend on QString::isNull() (no characters are written
either way), and add a missing article to the function's docs.
Change-Id: I5d6b31361522812b0db8303b93c43d4b9ed11933
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Now that we have QStringView::arg(), we can use it to implement a
similarly flexible QString::arg(). It's not as straight-forward as in
QStringView, though: QString has existing arg() overloads that all
become worse matches with the introduction of the new,
perfectly-forwarding overload.
So in order to allow calling of the other arg() functions, first
constrain the new arg() function to arguments that are convertible to
QString, QStringView, or QLatin1String, and then delegate to the
QStringView version. To stay compatible with the previous overloads,
which accepted anything that implicitly converts to QString (in
particular, QStringBuilder expressions), add a new overload of
qStringLikeToView, taking const QString &. This benefits the existing
QStringView and QLatin1View versions, too.
[ChangeLog][QtCore][QString] QString::arg(QString, ..., QString) can
now be called with more than nine arguments, as well as with
QStringViews.
Change-Id: I1e717a1bc696346808bcae45dc47762a492c8714
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>