summaryrefslogtreecommitdiffstats
path: root/src/corelib/tools/qmap.h
Commit message (Collapse)AuthorAgeFilesLines
* QMap: Use qHash SFINAE workaround with MSVCJøger Hansegård2024-03-241-2/+2
| | | | | | | | | | | | | | | | | Fixes failure to find qHash functions when building Squish. Here, QMap is used with custom types that do not have any associated qHash functions. It should therefore not require a qHash function to be usable with QMap. There is no indication in the build output where the instantiation came from. There's nothing in the output about the function it should have called, likely because no qHash functions exists. Amends: e1f45ad8187947e243c8247c5cbac2d884d68d55 Fixes: QTBUG-123310 Change-Id: Idb12fb6ffab06ce242c43f2c42ea7a105e8fa0f4 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* QMap: add missing qHash() overloadMarc Mutz2024-02-091-0/+27
| | | | | | | | | | | | | | | | | | | Found in API review, but not deemed important enough to still get into 6.7. Not implementing it for QMultiMap, because there we need to mod out order of equivalent elements. The GHS compiler acted up and tried to compile the noexcept specification, hitting non-existing qHash(QVariant) for QVariantMap and producing a hard error instead of SFINAE'ing out. As a work-around, establish an artificial SFINAE-friendly context, but only for that compiler. [ChangeLog][QtCore][QMap/QHash] Added qHash() overload for QMap. Change-Id: Ia7dbf488e8e5490962118e40581b7c4cc8ed95e5 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* QMap/QHash: s/QPair/std::pair/Marc Mutz2023-12-131-4/+4
| | | | | | | | | Also port from qMakePair to just braced initialization using CTAD. Task-number: QTBUG-115841 Pick-to: 6.7 Change-Id: Ib0ad55d7110521e34004dc9050022f9c0046722e Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
* Replace usages of Q_CLANG_QDOC with Q_QDOCLuca Di Sera2022-10-211-4/+4
| | | | | | | | | | | | | | | | | | | | | | | To allow the user to customize the C++ code that QDoc sees, so as to be able to work-around some limitations on QDoc itself, QDoc defines two symbols: Q_QDOC and Q_CLANG_QDOC, both of which are "true" during an entire execution of QDoc. At a certain point in time, QDoc allowed the user the choice between a custom C++ parser and a Clang based one. The Q_QDOC symbol would always be defined while the Q_CLANG_QDOC symbol would be defined only when the Clang based parser was chosen. In more recent times, QDoc always uses a Clang based parser, such that both Q_CLANG_QDOC and Q_QDOC are always defined, making them equivalent. To avoid using different symbols, and the possible confusion and fragmentation that derives from it, all usages of Q_CLANG_QDOC are now replaced by the equivalent usages of Q_QDOC. Change-Id: I5810abb9ad1016a4c5bbea99acd03381b8514b3f Reviewed-by: Kai Koehne <kai.koehne@qt.io>
* Use SPDX license identifiersLucie Gérard2022-05-161-39/+3
| | | | | | | | | | | | | 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>
* Associative containers: add a way to obtain a key/value rangeGiuseppe D'Angelo2022-03-041-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Our associative containers' iterator's value_type isn't a destructurable type (yielding key/value). This means that something like for (auto [k, v] : map) doesn't even compile -- one can only "directly" iterate on the values. For quite some time we've had QKeyValueIterator to allow key/value iteration, but then one had to resort to a "traditional" for loop: for (auto i = map.keyValueBegin(), e = keyValueEnd(); i!=e; ++i) This can be easily packaged in an adaptor class, which is what this commmit does, thereby offering a C++17-compatible way to obtain key/value iteration over associative containers. Something possibly peculiar is the fact that the range so obtained is a range of pairs of references -- not a range of references to pairs. But that's easily explained by the fact that we have no pairs to build references to; hence, for (auto &[k, v] : map.asKeyValueRange()) doesn't compile (lvalue reference doesn't bind to prvalue pair). Instead, both of these compile: for (auto [k, v] : map.asKeyValueRange()) for (auto &&[k, v] : map.asKeyValueRange()) and in *both* cases one gets references to the keys/values in the map. If the map is non-const, the reference to the value is mutable. Last but not least, implement pinning for rvalue containers. [ChangeLog][QtCore][QMap] Added asKeyValueRange(). [ChangeLog][QtCore][QMultiMap] Added asKeyValueRange(). [ChangeLog][QtCore][QHash] Added asKeyValueRange(). [ChangeLog][QtCore][QMultiHash] Added asKeyValueRange(). Task-number: QTBUG-4615 Change-Id: Ic8506bff38b2f753494b21ab76f52e05c06ffc8b Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* QtCore: replace qSwap with std::swap/member-swap where possibleMarc Mutz2022-01-201-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | qSwap() is a monster that looks for ADL overloads of swap() and also detects the noexcept of the wrapped swap() function, so it should only be used when the argument type is unknown. In the vast majority of cases, the type is known to be efficiently std::swap()able or to have a member-swap. Call either of these. For the common case of pointer types, circumvent the expensive trait checks on std::swap() by providing a hand-rolled qt_ptr_swap() template, the advantage being that it can be unconditionally noexcept, removing all type traits instantiations. Don't document it, otherwise we'd be unable to pick it to 6.2. Effects on Clang -ftime-trace of a PCH'ed libQt6Gui.so build: before: **** Template sets that took longest to instantiate: [...] 27766 ms: qSwap<$> (9073 times, avg 3 ms) [...] 2806 ms: std::swap<$> (1229 times, avg 2 ms) (30572ms) after: **** Template sets that took longest to instantiate: [...] 5047 ms: qSwap<$> (641 times, avg 7 ms) [...] 3371 ms: std::swap<$> (1376 times, avg 2 ms) [qt_ptr_swap<$> does not appear in the top 400, so < 905ms] (< 9323ms) As a drive-by, remove superfluous inline keywords and template ornaments. Task-number: QTBUG-97601 Pick-to: 6.3 6.2 Change-Id: I88f9b4e3cbece268c4a1238b6d50e5712a1bab5a Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* Q(Multi)Map: prevent dangling key/value after detach()Giuseppe D'Angelo2021-11-261-3/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Q(Multi)Map mutating functions that take reference to a key and/or a value (e.g. insert(), take(), etc.) must make sure that those references are still valid -- that is, that the referred objects are still alive -- after the detach() call done inside those functions. In fact, if the key/value are references into *this, one must take extra steps in order to preserve them across the detach(). Consider the scenario where one has two shallow copies of QMap, each accessed by a different thread, and each thread calls a mutating function on its copy, using a reference into the map (e.g. map.take(map.firstKey())). Let's call the shared payload of this QMap SP, with its refcount of 2; it's important to note that the argument (call it A) passed to the mutating function belongs to SP. Each thread may then find the reference count to be different than 1 and therefore do a detach() from inside the mutating function. Then this could happen: Thread 1: Thread 2: detach() detach() SP refcount != 1 => true SP refcount != 1 => true deep copy from SP deep copy from SP ref() the new copy ref() the new copy SP.deref() => 1 => don't dealloc SP set the new copy as payload SP.deref() => 0 => dealloc SP set the new copy as payload use A to access the new copy use A to access the new copy The order of ref()/deref() SP and the new copy in each thread doesn't really matter here. What really matters is that SP has been destroyed and that means A is a danging reference. Fix this by keeping SP alive in the mutating functions before doing a detach(). This can simply be realized by taking a local copy of the map from within such functions. remove() doesn't suffer from this because its implementation doesn't do a bare detach() but something slightly smarter. Change-Id: Iad974a1ad1bd5ee5d1e9378ae90947bef737b6bb Pick-to: 6.2 Reviewed-by: Marc Mutz <marc.mutz@qt.io> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Fix docs for comparison/debug/data stream operators of Qt containersSona Kurazyan2021-10-181-0/+10
| | | | | | | | | | | | | | Because of the constraints on comparison, debug and data stream operators, the return types for them look weird in docs. Conditionally use the actual return types, in case if Q_CLANG_QDOC is defined. Also add the docs of debug stream operators for types for which they were misssing. Task-number: QTBUG-97247 Pick-to: 6.2 Change-Id: I57f2c52bd3af805c7eeebb602c47de1e95ee09bd Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* corelib: Fix typos in source code commentsJonas Kvinge2021-10-121-1/+1
| | | | | | Pick-to: 6.2 Change-Id: Ic78afb67143112468c6f84677ac88f27a74b53aa Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* Fix compilation for recursive Qt containersSona Kurazyan2021-09-071-4/+4
| | | | | | | | | | | | | | | | | | | | The operator checks cause compilation errors when trying to check for their existence for recursive containers. This happens because of trying to check for the operators on the template parameter type(s), that inherit from the container itself, which leads to compilation errors. Introduced alternative versions of the operator checks (with _container suffix), that first check if the container is recursive, i.e. any of its template parameter types inherits from the given container, and skips the operator check, if that's the case. The fix is done for all Qt container types that had the problem, except for QVarLengthArray and QContiguousCache, which don't compile with recursive parameter types for unrelated reasons. Fixes: QTBUG-91707 Pick-to: 6.2 6.1 Change-Id: Ia1e7240b4ce240c1c44f00ca680717d182df7550 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Doc: Fix documentation issues for Qt CoreTopi Reinio2021-08-241-0/+16
| | | | | | | | | | | | | | * Tag deprecated Q(Multi)Map operators in the header to correctly match them with documentation \fn commands. * Add documentation for QByteArrayView comparison operators. * Add a dummy typedef 'jfieldID' for generating docs correctly on non-Android platforms * Fix other minor issues Pick-to: 6.2 Task-number: QTBUG-95860 Change-Id: I141d2f75d6aa10557aa374201f09ad74b4cd6e81 Reviewed-by: Paul Wicking <paul.wicking@qt.io>
* QMap: add operator+ and - for iteratorsGiuseppe D'Angelo2021-07-271-0/+80
| | | | | | | | | | | | | We missed the chance of deprecating them in 5.15, so they'll just add to the pain of porting to 6.0. We should not keep them around forever, though; QMap isn't random access and so its iterators should only have bidirectional APIs. Pick-to: 6.2 Fixes: QTBUG-95334 Change-Id: I3577f7d25e8ab793722d2f220fd27bc85c622b0d Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Fix quadratic performance hit in Q(Multi)Map::insert() with hintEdward Welbourne2021-07-201-9/+19
| | | | | | | | | | | | | | | | | | | | | | | The insert() overloads that took a const_iterator started by calling std::distance(begin(), pos) - which has a cost linear in how far pos is from begin() - in order to, after detach()ing, obtain an iterator at the same offset from the new begin(), using std::next() - also linear. This leads to quadratic behavior when large numbers of entries are added with constEnd() as the hint, which happened to be tested by tst_bench_qmap. That wasn't running, due to some assertion failures, but once those were fixed the hinted tests timed out after five minutes, where their unhinted peers completed comfortably within a second. Check whether detach() is even needed and bypass the std::distance() / std::next() linear delay when it isn't. This brings the hinted tests down to running faster than their unhinted equivalents. Pick-to: 6.1 6.2 Task-number: QTBUG-91713 Change-Id: I6b705bf8fc34e67aed2ac4b3312a836e105ca2f2 Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com> Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
* Associative containers: add erase_ifGiuseppe D'Angelo2020-12-021-0/+24
| | | | | | | | | | | | | | | | | | | | Use a trick similar to the one we use for their ranged constructors: support predicates that either take a container's iterator, or that take a std::pair (for STL compatibility). [ChangeLog][QtCore][QMap] Added removeIf() and erase_if(). [ChangeLog][QtCore][QMultiMap] Added removeIf() and erase_if(). [ChangeLog][QtCore][QHash] Added removeIf() and erase_if(). [ChangeLog][QtCore][QMultiHash] Added removeIf() and erase_if(). Change-Id: Ie40aadf6217d7a4126a626c390d530812ebcf020 Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QMap: code tidiesGiuseppe D'Angelo2020-12-011-22/+22
| | | | | Change-Id: I3a88cb2d307a44022df6d6045d99acfc9b1a1a0e Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Don't allow storing types that throw in the destructor in our containersLars Knoll2020-11-171-10/+15
| | | | | | | | | | | | | | | | | | | | | | Types that throw in their destructors are strongly discouraged in C++, and even the STL doesn't define what happens if such types are stored in their containers. Make this more explicit for Qt and disallow storing those types in our containers. This will hopefully preempty any potential future bug reports about us not handling such a case. It also helps simplify some code in QList and other cases and makes it possible to explicitly mark more methods as noexcept. Some care needs to be taken where to add the static asserts, so that we don't disallow forward declarations of types stored in containers. Place the static assert into the destructor of the container where possible or otherwise into the templated d-pointer. Change-Id: If3aa40888f668d0f1b6c6b3ad4862b169d31280e Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Make QMap and QMultiMap comparisons hidden friendsAllan Sandfeld Jensen2020-10-291-59/+31
| | | | | | Task-number: QTBUG-87975 Change-Id: I3c84a188cdbb0d09e0e7c66588c7638c8a8328fd Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Make Q(Multi)Map equality operators documentation-friendlyVolker Hilsheimer2020-10-231-1/+14
| | | | | Change-Id: I1a84c437bb19dd3c667596c59e1404bbbf39978e Reviewed-by: Paul Wicking <paul.wicking@qt.io>
* Consistenly deprecate QMultiMap insert, add moving unite overloadVolker Hilsheimer2020-10-171-19/+26
| | | | | Change-Id: I8d1d30f3962b0444c27591bf45b6b3c538172039 Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
* Long live Q_IMPLICIT!Giuseppe D'Angelo2020-10-141-2/+2
| | | | | | | | | | | | | C++20 will give us explicit(bool). While we can't use it just yet in its full potential, we can introduce a macro to start marking our implicit conversions (aka `explicit(false)`), removing the need for /* implicit */-like comments. Port a few usages to it. Change-Id: I336d5e4c8d51d8329627900d1059e59062c5cafd Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Fix qdoc warnings for QMap/QMultiMapVolker Hilsheimer2020-10-011-16/+19
| | | | | | | | | | | | | | | | | | | | | | | | These containers have most of their operators as non-members, except those declared as hidden friends in the iterator classes, which will be fixed in qdoc. QMultiMap doesn't have an operator[] (which might be unintentional). Deprecate QMultiMap::insert/insertMulti APIs, as the documentation suggests that those are just compatibility overloads. Add documentation for the rvalue-overload of QMap/QMultiMap::insert. Note that this overload does not exist for QHash/QMultiHash. Also, it seems from the implementation that the moved-from map is not reset to the empty map if it did share data with another copy. Not addressed: QMap and QMultiMap have the special 5 implicitly generated by the compiler, so these functions are not declared anywhere, which results in qdoc warnings. qdoc could generate the documentation automatically, if it can know that those members exist. Change-Id: I0608b57c8c3793fedd304a4c7b10e607a24ad5f6 Reviewed-by: Paul Wicking <paul.wicking@qt.io>
* Remove some deprecation comments from qmap.hEdward Welbourne2020-09-211-6/+0
| | | | | | | | | Lars says documenting that the methods are slow is sufficient, no need to deprecate them. Task-number: QTBUG-85700 Change-Id: I7b1d19e91e30205df7d8198e3704cecc72a853e0 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* QMultiMap: fix regression in find(Key, T)Giuseppe D'Angelo2020-08-191-5/+12
| | | | | | | | | | | | | | | | | | | 1) Implementing the const version in terms of the non-const version exposes to accidental detaches. Avoid that. 2) The non-const version has to detach, just like find(Key), or doing a comparison like find(Key, T) != end() might report a wrong result. 3) Properly check if the value was found by checking find_if's return value (against its second parameter, the end of the iterated range). If the value was NOT found, then return the map's end() (again because clients of find() will check against end()). Change-Id: I03533e89f1e7a52ad888d159d78f38002765953c Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
* QMultiMap: fix remove(Key, T) when key/value belong to the mapGiuseppe D'Angelo2020-08-191-3/+9
| | | | | | | | | | | | | | Just like any other container, it's legitimate for the user to pass key/values belonging to the same container. Q(Multi)Map::remove(Key) are already safe (either they call erase() directly on std::(multi)map, where it does the right thing, or they skip elements while detaching). However, QMultiMap::remove(Key, T) wasn't safe in this regard (the implementation is hand rolled), so take copies before start erasing. Change-Id: I87767d608b83216a6ff264fb6c8f145fdb5934f8 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QMultiMap: add constructors from QMapGiuseppe D'Angelo2020-08-101-0/+31
| | | | | | | | | | | We can provide those. They don't lose information, do not have the problem we face at offering ranged constructors (namely the order of duplicate keys), and have a distinct advantage over ranged constructors: a non-shared rvalue QMap can be "upgraded" to a QMultiMap without allocating memory for the multimap. Change-Id: Ic23c83927c05a210bc1f0050006c9f26365d3916 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QMap/QMultiMap: use =default for their default constructorsGiuseppe D'Angelo2020-08-071-2/+2
| | | | | Change-Id: I48e5bd8367fc6040128a50cd08c803310d3a4507 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QMultiMap: add range eraseGiuseppe D'Angelo2020-08-061-48/+61
| | | | | | | | Also remove duplication by centralizing the main code for erase(), and implement erase(pos) in terms of erase(first, last). Change-Id: Ie0272ebac92fd7da48c31f9d68e69a2faa583bbc Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QMap: fix insert() rvalue overloadsGiuseppe D'Angelo2020-08-061-0/+12
| | | | | | | | Receiving an rvalue still requires to check whether the parameter is detached, otherwise we can't steal its backing std::map. Change-Id: Ie88dbf39fd777112ad7bb20a46d5c2d65be8eb3d Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Long Live QMap as a refcounted std::map!Giuseppe D'Angelo2020-08-061-1045/+1068
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ... and QMultiMap as std::multimap. Just use the implementation from the STL; we can't really claim that our code is much better than STL's, or does things any differently (de facto they're both red-black trees). Decouple QMultiMap from QMap, by making it NOT inherit from QMap any longer. This completes the deprecation started in 5.15: QMap now does not store duplicated keys any more. Something to establish is where to put the QExplictlySharedDataPointer replcement that is in there as an ad-hoc solution. There's a number of patches in-flight by Marc that try to introduce the same (or very similar) functionality. Miscellanea changes to the Q(Multi)Map code itself: * consistently use size_type instead of int; * pass iterators by value; * drop QT_STRICT_ITERATORS; * iterators implictly convert to const_iterators, and APIs take const_iterators; * iterators are just bidirectional and not random access; * added noexcept where it makes sense; * "inline" dropped (churn); * qMapLessThanKey dropped (undocumented, 0 hits in Qt, 1 hit in KDE); * operator== on Q(Multi)Map requires operator== on the key type (we're checking for equality, not equivalence!). Very few breakages occur in qtbase. [ChangeLog][Potentially Source-Incompatible Changes] QMap does not support multiple equivalent keys any more. Any related functionality has been removed from QMap, following the deprecation that happened in Qt 5.15. Use QMultiMap for this use case. [ChangeLog][Potentially Source-Incompatible Changes] QMap and QMultiMap iterators random-access API have been removed. Note that the iterators have always been just bidirectional; moving an iterator by N positions can still be achieved using std::next or std::advance, at the same cost as before (O(N)). [ChangeLog][Potentially Source-Incompatible Changes] QMultiMap does not inherit from QMap any more. Amongst other things, this means that iterators on a QMultiMap now belong to the QMultiMap class (and not to the QMap class); new Java iterators have been added. Change-Id: I5a0fe9b020f92c21b37065a1defff783b5d2b7a9 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Constrain the comparison operators for our container classesLars Knoll2020-07-081-22/+22
| | | | | | | | | | | | This had already been in very few places, where we ran into issues with this before. More generic constraints here will significantly reduce the amount of error messages a user has to parse in case he tries to instantiate an operator by accident (or with a lacking comparison operator for one of it's template arguments). Change-Id: I1521d19c55d99732d9742402bd534c390a8e4242 Reviewed-by: Paul Wicking <paul.wicking@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Add type traits to safely determine the existence of comparison operatorsLars Knoll2020-07-081-0/+1
| | | | | | | | | | | | | | | | | | Containers often define an operator==() or operator<() which is very useful for generic code. But those operators can usually not be instantiated if the template argument doesn't implement the operator. This sometimes leads to the compiler trying all possible template expansions and implicit conversions for the type, giving extremely long error messages. The traits support can be used to safely constrain those operators. Being able to safely detect this will also allow us to fold the comparison support that is currently a large cludge for user types directly into QMetaType. Change-Id: Ib84afb5348c3eb0be5161d6ba9d5fe237709c65f Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Use qsizetype for size related methods in QMapLars Knoll2020-03-141-28/+28
| | | | | | | This allows QMap to hold more than 2^31 entries on 64 bit systeems. Change-Id: Ia6abd3441f9bc0c7e1a01b78726b5c32209542fa Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* QHash/QMap: don't return const from value(), key()Marc Mutz2020-03-051-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | ... it breaks move semantics. We can change these, since they're templates and a short survey shows that no-one in Qt was crazy enough to inherit an exported class from QHash or QMap. Otherwise this would be BiC on MSVC, which encodes the return type. There's also no safety benefit here, as none of the overloads returns by reference, so users cannot expect map.value(key).mutate() to have an effect on the element in the container. In this, key() and value() differ from op[], which also returns const, but whose overload returns a reference. op[] is therefore not proposed here. [ChangeLog][QtCore][QHash/QMultiHash/QMap/QMultiMap] The value() and key() member functions now return T (was: const T), enabling move semantics on their return values. Change-Id: I0e5f53f9834caad458e3bde27f1daacbb4bac71b Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Merge remote-tracking branch 'origin/5.15' into devLars Knoll2020-03-041-30/+23
|\ | | | | | | Change-Id: I99ee6f8b4bdc372437ee60d1feab931487fe55c4
| * QMap: undeprecate QMap::count(Key)Mårten Nordheim2020-03-031-25/+18
| | | | | | | | | | | | | | For compatibility with std::map Change-Id: Icba536244aadcad97c59dfd4bb22a7fdea881a7b Reviewed-by: Lars Knoll <lars.knoll@qt.io>
| * QMap/QHash: Use versioned deprecation macroMårten Nordheim2020-03-031-6/+6
| | | | | | | | | | | | | | Because then it can be configured Change-Id: Ib4c20dd64bedfe2ebadf13283698c50d4c0bc527 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* | Merge remote-tracking branch 'origin/5.15' into devQt Forward Merge Bot2020-02-261-19/+22
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: examples/network/bearermonitor/CMakeLists.txt examples/network/CMakeLists.txt src/corelib/tools/qlinkedlist.h src/sql/kernel/qsqldriver_p.h src/sql/kernel/qsqlresult_p.h src/widgets/kernel/qwidget.cpp src/widgets/kernel/qwidget_p.h tests/auto/network/socket/platformsocketengine/tst_platformsocketengine.cpp tests/auto/network/socket/qtcpsocket/tst_qtcpsocket.cpp tests/auto/tools/moc/allmocs_baseline_in.json Change-Id: I21a3c34570ae79ea9d30107fae71759d7eac17d9
| * Doc: Fix documentation warnings for Qt CoreTopi Reinio2020-02-251-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - 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>
| * QMultiMap: Work around compiler problem in MSVC 2017Oliver Wolff2020-02-201-19/+18
| | | | | | | | | | | | | | | | | | | | In more complex projects (like MuseScore) it is possible, that MSVC 2017 chokes on the usage of "using typename ...". Just fully specify the iterators when they are used. Fixes: QTBUG-82166 Change-Id: I5e7882a0963445fc8529cfcb59d2aae606a2777e Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* | Merge remote-tracking branch 'origin/5.15' into devQt Forward Merge Bot2020-01-191-146/+205
|\| | | | | | | Change-Id: I68702c9f9680772d332b5bb777ddd2663168abd5
| * QMap: deprecate insertMulti, unite and friendsMårten Nordheim2020-01-171-146/+205
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | insertMulti and unite will silently transform a QMap into a multi-map which is not behavior we want to keep around anymore and as such is being deprecated. QMap functions that only make sense in a multi-map scenario are also deprecated and the implementation is moved to QMultiMap where it makes sense. Use QMultiMap if multiple keys are desired and insert(const QMap &) if a non multi-map-converting unite is desired. [ChangeLog][QtCore][QMap] insertMulti(), unite(), values(Key), uniqueKeys(), count(Key) is now deprecated. Please use QMultiMap instead. Task-number: QTBUG-35544 Change-Id: I158c938ceefb5aaba0e6e7513b2c26a64d29d521 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* | Merge remote-tracking branch 'origin/5.15' into devLiang Qi2020-01-041-0/+44
|\| | | | | | | | | | | | | | | | | | | | | | | Conflicts: src/corelib/tools/qvector.h Make QVector(DataPointer dd) public to be able to properly merge 5b4b437b30b320e2cd7c9a566999a39772e5d431 from 5.15 into dev. src/widgets/kernel/qapplication.cpp tests/auto/tools/moc/allmocs_baseline_in.json Done-With: Christian Ehrlicher <ch.ehrlicher@gmx.de> Change-Id: I929ba7c036d570382d0454c2c75f6f0d96ddbc01
| * Add QMap::insert(const QMap &map)Mårten Nordheim2019-12-121-0/+44
| | | | | | | | | | | | | | | | | | As opposed to unite(), this inserts one map into the other without duplicating elements. Task-number: QTBUG-35544 Change-Id: Ie8ab350b29148851a3176cef1007e8a4ca82c273 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* | Get rid of QT_STRICT_ITERATORSLars Knoll2019-11-041-18/+3
| | | | | | | | | | | | | | | | | | | | | | The concept was a nice idea to avoid accidental detach() calls in implicitly shared containers, but it conflicts with a C++11 compatible API for them, with signatures for modifying methods taking a const_iterator as argument and returning an iterator (e.g. iterator erase(const_iterator)). Change-Id: Ia33124bedbd260774a0a66f49aedd84e19c9971b Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* | Get rid of unsharable containersLars Knoll2019-10-301-11/+0
| | | | | | | | | | | | | | | | The support for unsharable containers has been deprecated since Qt 5.3.0, so let's finally remove support for them. Change-Id: I9be31f55208ae4750e8020b10b6e4ad7e8fb3e0e Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* | Replace Q_ALIGNOF usage in qtbase with C++11 alignof keywordVolker Hilsheimer2019-10-291-2/+2
|/ | | | | | | | | | | | | | | | The macro is not documented, so not part of the public Qt API. It is made obsolete by the alignof keyword in C++11. Remove the usage of the macro across qtbase, in particular the workarounds for compilers that didn't support alignof, and that will not be supported in Qt 6. The macro definition is left in place, no need to break existing code. Task-number: QTBUG-76414 Change-Id: I1cfedcd4dd748128696cdfb546d97aae4f98c3da Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
* Remove handling of missing Q_COMPILER_INITIALIZER_LISTSAllan Sandfeld Jensen2019-05-021-9/+2
| | | | | | Change-Id: Id65b39c787235a051262544932e6717d076f1ea0 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Remove handling of missing =delete and =default supportAllan Sandfeld Jensen2019-05-021-1/+1
| | | | | Change-Id: I006dfd0b7cfa3bda5e5ab01bcefa851f031dfe0e Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Remove handling of missing Q_COMPILER_RVALUE_REFSAllan Sandfeld Jensen2019-05-011-4/+0
| | | | | | | | Remove remaining handling of missing support for rvalue refs. Change-Id: I78bab8bccfeeb9c76f464f345874364a37e4840a Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-04-27 01:31:38 +0000