summaryrefslogtreecommitdiffstats
path: root/src/corelib/text/qbytearray.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>
* QS(V)/QBA(V)/QL1S::lastIndexOf: fix the offset calculationsGiuseppe D'Angelo2021-08-191-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When trying to fix 0-length matches at the end of a QString, be83ff65c424cff1036e7da19d6175826d9f7ed9 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>
* Consolidate documentation of floating-point formatting codeEdward Welbourne2021-08-031-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Move the documentation of the format and precision parameters to QLocale::toString(double, char, int), reference it from various QString methods (instead of repeating there and referencing one of those from QLocale). Add brief first lines for various documentation comments. Mention the special handling of negative precision in the moved documentation. Mention QLocale::FloatingPointShortest, add its type to \sa lines of methods it affects. Change a comment on some code implementing its special treatment to make clear that it does apply to 'e' and 'f' formats, not only to 'g', even though it has no overt special handling in that code; and update docs to report the undocumented behavior the comment previously described. Document how infinity and NaN are represented. Be somewhat more consistent about single-quoting the format names where referred to and applying \c to character constants. Make clear what things are different between different methods using these parameters. Reference QString::number() from QByteArray's relevant methods, since they share its quirks. In the process, rename the format and precision parameters of relevant functions so they're consistently named, replacing a mixture of abbreviated forms. Pick-to: 6.2 Change-Id: I077521b30346000e4b4f6968a8e750e934f72937 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* QByteArray: don't coerce negative to unsigned for any baseEdward Welbourne2021-08-021-3/+3
| | | | | | | | | | | | | | | | This follows up on commit 98666c8afc80cccb80ca4426b97ec52916c6e610, which did the same for QString. If someone wants to get formatting suitable to an unsigned value, they can cast the value to that unsigned type and the correct overload shall pick it up. [ChangeLog][Important Behavior Changes] QByteArray's formatting of negative whole numbers to bases other than ten now, like QString's (since Qt 6.0), formats the absolute value and prepends a minus sign. Task-number: QTBUG-53706 Pick-to: 6.2 Change-Id: I91fee23d25ac0d5d5bcfcbeccbac1386627c004a Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QByteArray: Move some free-functions aroundMårten Nordheim2021-05-201-57/+0
| | | | | | | | | | Most of them go to qbytearrayalgorithms.h while the deprecated (inline) version of qChecksum goes to qbytearrayview.h In preparation for adding compare to QByteArrayView. Change-Id: If7f65e9e7cd74838e11ebdb952309b811cef079d Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Add literal operators for QString and QByteArrayAndrei Golubev2021-03-301-0/+7
| | | | | | | | | | | | [ChangeLog][QtCore][QString] Added literal operator u"..."_qs that converts a char16_t string literal to QString [ChangeLog][QtCore][QByteArray] Added literal operator "..."_qba that converts char string literal to QByteArray Change-Id: I4aa59b28cc17bff346b378eb70008fb8185d21ac Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Use Core library for qmake instead of the Bootstrap libraryAlexey Edelev2021-02-251-1/+1
| | | | | | | | | | | | | | | | | | | Move the qmake-specific logic of the QLibraryInfo class to qmake internals. 'qconfig.cpp.in' now stores information about the library info entries to keep them consistent between qmake and the Core library. qmake requires specific features enabled in the Core library, so building qmake will be skipped if the features are not enabled. All flags directly related to the qmake have been removed from Core lib. Remove all bootstrap related sections from qmake CMakeLists.txt Task-number: QTBUG-89369 Change-Id: I26de157d3bfd4a5526699296e9d46e1c180b89ae Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Kai Koehne <kai.koehne@qt.io>
* Workaround bogus compiler warningFabian Kosmale2020-12-101-1/+10
| | | | | | | | | gcc 9.x (but not 10.x) issues a bogus warning when strlen is used on a string literal; disable the warning for those versions. Upstream bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91490 Change-Id: I7a2a4d0f6ddafcafcd9fcc62fc41ad5d78e61627 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* QString/QByteArray: add erase/erase_ifGiuseppe D'Angelo2020-12-011-0/+18
| | | | | | | | | | | | | [ChangeLog][QtCore][QString] Added erase() and erase_if() for consistent container erasure. [ChangeLog][QtCore][QByteArray] Added erase() and erase_if() for consistent container erasure. Change-Id: I23e8565d39044c1f1d756500589c1f2b65e1a88f Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QString/QByteArray: add erase() for iteratorsGiuseppe D'Angelo2020-11-261-0/+1
| | | | | | | | | | | | | Otherwise they're not usable with iterator-based algorithms that e.g. remove, partition and the like. [ChangeLog][QtCore][QString] Added erase(). [ChangeLog][QtCore][QByteArray] Added erase(). Change-Id: I78829b1a5365dd53b6b6423ceedbc52edeafbc63 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
* Add QByteArray::insert(qsizetype, const QByteArray &)Mårten Nordheim2020-11-111-0/+4
| | | | | | | | | | | | | | | | For consistency with append and prepend we should have an overload for insert() as well. This also enables insert() to be used with QStringBuilder, i.e. qba.insert(2, qba2 + "abc"). Because simply adding a const QByteArray & overload causes ambiguity with QByteArrayView we also add a const char * overload. Add some extra test-cases. Two for QByteArrayView since it's not directly tested anymore. One for inserting self directly. Change-Id: Ieb43a6a7d1afbb498bc89c690908d7f0faa94687 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Clean up out allocation handlingLars Knoll2020-11-041-10/+8
| | | | | | | | | | Get rid of the allocation options inside the flags field of QArrayData, they are really a completely separate thing. Change-Id: I823750ab9e4ca85642a0bd0e471ee79c9cde43fb Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Avoid expensive iterator calculations in append()Lars Knoll2020-11-041-1/+1
| | | | | | | | | | | | | Avoid moving data inside the array to create free space at one end. This is a performance bottleneck, as it required quite a lot of calculations for every insert. Rather reallocate and grow in this case, so we only need to do expensive work when we reallocate the array. Change-Id: Ifc955fbcf9967c3b66aa2600e0627aac15f0c917 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
* Make QByteArray comparison operators hidden friendsVolker Hilsheimer2020-10-291-50/+66
| | | | | | | | | | Also for QByteArray::FromBase64Result, to reduce ADL noise. Add explicit overload for comparison with nullptr to avoid ambiguous overload errors with '0' comparisons. Change-Id: I7ff9dbc90581707856c10cf7fb835175dfcdb55e Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
* QByteArray: make (ap|pre)pend(const QByteArray &) consider reservedMårten Nordheim2020-10-281-2/+1
| | | | | | | | | | Append was previously optimized for lhs being empty but it should've also taken into account if space had been reserved. Apply the same optimization to prepend while we're at it. Change-Id: I5e5d33a3189b9ad88d45e858a2ac412cbc294f79 Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Centralize the implementation of move assignment operatorsGiuseppe D'Angelo2020-10-031-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At the moment we have two main strategies for dealing with move assignment in Qt: 1) move-and-swap, used by "containers" (in the broad sense): containers, but also smart pointers and similar classes that can hold user-defined types; 2) pure swap, used by containers that hold only memory (e.g. QString, QByteArray, ...) as well as most implicitly shared datatypes. Given the fact that a move assignment operator's code is just boilerplate (whether it's move-and-swap or pure swap), provide two _strictly internal_ macros to help write them, and apply the macros across corelib and gui, porting away from the hand-rolled implementations. The rule of thumb when porting to the new macros is: * Try to stick to the existing code behavior, unless broken * if changing, then follow this checklist: * if the class does not have a move constructor => pure swap (but consider ADDING a move constructor, if possible!) * if the class does have a move constructor, try to follow the criteria above, namely: * if the class holds only memory, pure swap; * if the class may hold anything else but memory (file handles, etc.), then move and swap. Noteworthy details: * some operators planned to be removed in Qt 6 were not ported; * as drive-by, some move constructors were simplified to be using qExchange(); others were outright broken and got fixed; * some contained some more interesting code and were not touched. Change-Id: Idaab3489247dcbabb6df3fa1e5286b69e1d372e9 Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
* Switch Q_DECL_DEPRECATED to use C++14 [[deprecated]]Allan Sandfeld Jensen2020-10-031-6/+6
| | | | | | | | | | As a C++ attribute it must be on the beginning of the line or after the function name however. And for friend declarations can only be on the definition. Change-Id: I456884428f36e1f1c621089c7b1addee13ada0fe Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* make {QString,QByteArray}::squeeze() work without prior reserve()Oswald Buddenhagen2020-09-281-1/+1
| | | | | | | | | | | | | string-shortening operations never throw away capacity (unless detaching), so it may very much make sense to squeeze a string whose capacity was not explicitly reserved. this does in fact restore the behavior prior to commit a3aa2fcf, which changed it presumably only due to not considering the case above. Change-Id: I0d7919a1724dd3ecc6cd4cbd7236eb52067f0a1c Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
* Replace Q_REQUIRED_RESULT with [[nodiscard]]Allan Sandfeld Jensen2020-09-251-41/+41
| | | | | | | It was already used many places directly making the code inconsistent. Change-Id: I3b14bc6c333640fb3ba33c71eba97e78c973e44b Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Remove ### comment on QT5_NULL_STRINGSEdward Welbourne2020-09-231-1/+1
| | | | | | | | | Commented recommended turning it off by default in Qt 6, but Lars changed his mind once he saw how much broken on doing that. Task-number: QTBUG-85700 Change-Id: I1aeec408400978821e0e64d082dbb73cf982e54a Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* QString/QBA: change realloc*Data signatures to use qsizetypeAndrei Golubev2020-09-101-5/+5
| | | | | | | | | | Changed reallocData, reallocGrowData signatures to use qsizetype instead of size_t Change-Id: Iebe7def5430d3d3f4660e19cb6c12612543c5abc Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Remove '\0' space reservation logic in QByteArrayAndrei Golubev2020-09-101-6/+5
| | | | | | | | | Changed QByteArray to use implicit element reserved by QArrayData Task-number: QTBUG-84320 Change-Id: I2a0091c814a47a5c052da7a83d10cb641834c7bd Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Add QByteArrayView overloads for push_back and push_frontLars Knoll2020-09-031-18/+16
| | | | | | | | Change-Id: If70f3ac6764958d92dcbab44432b4f4994d20405 Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
* Clean up the QByteArray API and implementationLars Knoll2020-09-031-37/+50
| | | | | | | | | | | | | | Add overloads using a QByteArrayView where it makes sense, and call those inline from the other overloads. Remove overloads that are not required anymore (due to implicit conversion of a const char * to a QByteArrayView). Guard all implementations against passing this object to them. Change-Id: I930156f8b05ce72c32cb8201c70513f2e6e19d3e Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* QByteArray: Disregard space at front during ::reserve(...)Mårten Nordheim2020-09-021-1/+1
| | | | | | | | | | | | Traditionally when calling reserve it's because you expect to append up to X amount of bytes. We should keep that behavior the same. With another patch still in the works current behavior caused an issue with QStringBuilder in QNAM, as mirrored in the testcase attached. Change-Id: I9792a8f158fc9235e3de48ac8b06ac2c10e7f3dc Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Support GrowsBackwards in QByteArrayAndrei Golubev2020-08-291-0/+1
| | | | | | | | | | | | | | | Updated main QByteArray operations to support prepend-optimization path There are still many things to consider especially algorithms that use QByteArray::data() or do raw memory operations (e.g. memcpy) regardless of the underlying memory layout, which was somewhat valid before but will likely break now given free space > 0 at the beginning of the byte array memory. Looked at existing cases in the scope of QByteArray, they seem to be OK. Hopefully, CI would find missed violations if any Task-number: QTBUG-84320 Change-Id: I7990cda165b8e77a397e41df4e145468e7a86be0 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Pass QByteArrayView by valueLars Knoll2020-08-271-3/+3
| | | | | | Change-Id: I65df03e7781bac63d98b8d3b59568841601d8f25 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
* Inline the equality operatorLars Knoll2020-08-271-9/+8
| | | | | | | There's no reason to have this out of line. Change-Id: I52aa2ba941f9c81c2194865b156dbc0a2104363b Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Change QByteArray to handle large arraysLars Knoll2020-08-271-81/+80
| | | | | | | | | | Use qsizetype throughout. Change-Id: I787af7fcfa17e1be87decb64c41c609cc24be117 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Oliver Wolff <oliver.wolff@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Add back QByteArray's relational operators taking QStringSona Kurazyan2020-08-261-0/+9
| | | | | | | | | | | | | QString still has the overloads of relational operators taking QByteArray. Add back QByteArray's relational operators taking QString for symmetry. See also the comments of d7ccd8cb4565c8643b158891c9de3187c1586dc9 for more details. [ChangeLog][EDITORIAL] Remove the changelog about QString/QByteArray operators being removed. They're back. Change-Id: I22c95e727285cf8a5ef79b3a4f9d45cb66319252 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Remove binary compat sources for qbytearray and qstringAllan Sandfeld Jensen2020-08-191-11/+1
| | | | | | | No longer needed in Qt6. Change-Id: I29567e175e07cc3658f0619acfd604abf64f6459 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Introduce QByteArrayViewSona Kurazyan2020-07-081-41/+41
| | | | | | | | | | | | | | | | | | | | Created a QByteArrayView in symmetry with QStringView. Added the basic tests symmetrical to QStringView tests. Moved the implementations of non-modifying methods of QByteArray to namespace QtPrivate, to be reused inline from both QByteArray and QByteArrayView. Changed QByteArray's counterparts of those methods to take QByteArrayView as argument instead of QByteArray. Removed QByteArray's operator QNoImplicitBoolCast(), because it was causing ambiguity when calling those methods with QByteArray argument (it was there to perevnt if(!ba)/if(ba) from compiling, but currently that would be ambiguous and won't compile anyway). [ChangeLog][QtCore][QByteArrayView] New class. Task-number: QTBUG-84321 Change-Id: I05f92e654cf65c95f2bb31b9c9018746ac110426 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Try to workaround bogus compiler warning in gcc 9 for ARMv7Lars Knoll2020-07-061-2/+1
| | | | | | | | | | | | | | | | | | | | | | | ../../src/corelib/io/qurlidna.cpp: In function ‘QString qt_ACE_do(QStringView, AceOperation, AceLeadingDot)’: ../../src/corelib/io/qurlidna.cpp:2543:23: error: ‘int __builtin_memcmp_eq(const void*, const void*, unsigned int)’ reading 8 bytes from a region of size 2 [-Werror=stringop-overflow=] if (memcmp(result.constData() + prevLen, acePrefixUtf16, sizeof acePrefixUtf16) == 0) ~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cc1plus: all warnings being treated as errors In function ‘bool operator==(const QByteArray&, const QByteArray&)’, inlined from ‘virtual void (* QLinuxFbIntegration::platformFunction(const QByteArray&) const)()’ at ../../src/plugins/platforms/linuxfb/qlinuxfbintegration.cpp:185:18: include/QtCore/../../../../src/corelib/text/qbytearray.h:571:45: error: ‘int __builtin_memcmp_eq(const void*, const void*, unsigned int)’ reading 17 bytes from a region of size 1 [-Werror=stringop-overflow=] The warnings/errors are bogus. Fix them by using QStringView::sliced() and de-inlining the comparison operator for QByteArray. Change-Id: I24956fe74a7989e75cd03d717570b8fca493ab23 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Rename from() to sliced()Lars Knoll2020-07-061-1/+1
| | | | | | | | 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>
* Make QArrayDataPointer::size a qsizetypeLars Knoll2020-07-061-1/+1
| | | | | | | | This is a next step towards making QList, QString and QByteArray able to deal with large sizes. Change-Id: Icad49b33f503401ac4912678b2f88584c6f91a63 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Get rid of shared null for QByteArray, QString and QVectorLars Knoll2020-07-061-18/+28
| | | | | | | | | | | | | | As a side effect, data() can now return a nullptr. This has the potential to cause crashes in existig code. To work around this, return an empty string from QString::data() and QByteArray::data() for now. For Qt 6 (and once all our internal issues are fixed), data() will by default return a nullptr for a null QString, but we'll offer a #define to enable backwards compatible behavior. Change-Id: I4f66d97ff1dce3eb99a239f1eab9106fa9b1741a Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Remove QByteArray's methods taking QString and their usesSona Kurazyan2020-06-251-20/+0
| | | | | | | | | | [ChangeLog][QtCore][QByteArray] Remove method overloads taking QString as argument, all of which were equivalent to passing the toUtf8() of the string instead. Change-Id: I9251733a9b3711153b2faddbbc907672a7cba190 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Rename new slice() method sliced()Marc Mutz2020-06-111-1/+1
| | | | | | | | | | | | | | 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>
* Implement first/last/from and slice() for string-like classesLars Knoll2020-06-081-1/+10
| | | | | | | | | | | | 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>
* Add missing number/setNum() overloadsLars Knoll2020-05-281-0/+8
| | | | | | | | QString has the overloads taking a long/ulong. QByteArray also has toLong/ULong(), so add these to make the API symmetric. Change-Id: I6d1f98ca95fabd32b012f1c3df603dc54e187ec3 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* QByteArrayLiteral: Remove const temporary that may prevent optimizationAlbert Astals Cid2020-05-081-2/+1
| | | | | | | | | clang-tidy 10 was complaining about http://clang.llvm.org/extra/clang-tidy/checks/performance-no-automatic-move.html Pick-To: 5.15 Change-Id: I63ba4111e01bb9d3ee87940253c4a79cc42c0bdf Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Change qHash() to work with size_t instead of uintLars Knoll2020-04-091-1/+1
| | | | | | | | | | | This is required, so that QHash and QSet can hold more than 2^32 items on 64 bit platforms. The actual hashing functions for strings are still 32bit, this will be changed in a follow-up commit. Change-Id: I4372125252486075ff3a0b45ecfa818359fe103b Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Merge remote-tracking branch 'origin/5.15' into devQt Forward Merge Bot2020-03-111-4/+4
|\ | | | | | | Change-Id: Ibee5acec72a1a1769d4bc5f23f56c7dc8d4cf3cb
| * QString/QByteArray: make all symmetry-checked member-compare() combinations ↵Marc Mutz2020-03-051-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | noexcept In QByteArray, they were just not marked as such. In QString and QStringRef, the implicit conversion from QChar to QString would destroy it. Add a QChar overload, delegating to QStringView. Added docs for the new overloads, copying from the nearest neighbor so as to not look out of place. All string classes use different wording for these functions. A cleanup of this state of affairs is out of the scope of this patch. Change-Id: I0b7b1d037aa229bcaf29b793841a18caf977d66b Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* | MSVC: Fix integer conversion warnings in containersFriedemann Kleint2020-01-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Add some casts, fixing warnings like: src/corelib/text/qbytearray.h(490): warning C4267: 'initializing': conversion from 'size_t' to 'int', possible loss of data src/corelib/text/qstring.h(1045): warning C4267: 'initializing': conversion from 'size_t' to 'int', possible loss of data src/corelib/tools/qarraydatapointer.h(80): warning C4267: 'initializing': conversion from 'size_t' to 'int', possible loss of data src/corelib/tools/qarraydatapointer.h(75): warning C4267: 'initializing': conversion from 'size_t' to 'int', possible loss of data src/corelib/text/qbytearray.h(490): warning C4267: 'initializing': conversion from 'size_t' to 'int', possible loss of data Change-Id: I221db4d5b660224f0fc1869248802c496db1b91c Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* | Merge remote-tracking branch 'origin/5.15' into devQt Forward Merge Bot2019-12-111-1/+1
|\| | | | | | | | | | | | | Conflicts: tests/auto/sql/kernel/qsqlquery/tst_qsqlquery.cpp Change-Id: I6b82507bf9a80a374c40393e72f4843f1557de89
| * Merge remote-tracking branch 'origin/5.14' into 5.15Liang Qi2019-12-101-1/+1
| |\ | | | | | | | | | | | | | | | | | | Conflicts: tests/auto/network/kernel/qnetworkinterface/BLACKLIST Change-Id: I1e8866c63b54bcd95fc2a044276ee15b7f60e79a
| | * Don't wrap feature detection macros with QT_HAS_FOO() variantsTor Arne Vestbø2019-12-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Using wrappers for these macros is problematic when for example passing the -frewrite-includes flag to preprocess sources before shipping off to distcc or Icecream. It will also start producing warnings when compilers implement http://eel.is/c++draft/cpp.cond#7.sentence-2. See for example https://reviews.llvm.org/D49091 Both https://clang.llvm.org/docs/LanguageExtensions.html and the SD-6 document at https://isocpp.org/std/standing-documents/sd-6-sg10-feature-test-recommendations recommend defining '__has_foo(x) 0' as a fallback for compilers without the macros, so that's what we go for. Change-Id: I0298cd3b4a6ff6618821e34642a5ddd6728be767 Reviewed-by: Alex Richardson <arichardson.kde@gmail.com> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | | Merge remote-tracking branch 'origin/5.15' into devQt Forward Merge Bot2019-12-091-3/+60
|\| | | | | | | | | | | Change-Id: Ia24cc8b86def0d9d9c17d6775cc519e491b860b1
| * | QByteArray: add a strict mode to fromBase64Giuseppe D'Angelo2019-12-051-1/+59
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | QByteArray::fromBase64 was liberal in its input, simply skipping over invalid characters. As a side-effect of this, it had no error reporting, meaning it could not be used to convert fromBase64 _and_ validate the input in one go. Add more option flags to make fromBase64 strictly validate its input. Since we want to know whether it has succeeded or not, and the existing fromBase64 overloads do not allow for that, introduce a new function that returns an optional-like datatype. While at it: base64 decoding can be done in-place; add an rvalue overload to enable this use case. [ChangeLog][QtCore][QByteArray] Added the new fromBase64Encoding function. [ChangeLog][QtCore][QByteArray] Added new flags to make fromBase64 / fromBase64Encoding strictly validate their input, instead of skipping over invalid characters. Change-Id: I99cd5f2230f3d62970b28b4cb102913301da6ccd Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-15 11:02:47 +0000