summaryrefslogtreecommitdiffstats
path: root/src/corelib/tools/qhashfunctions.h
Commit message (Collapse)AuthorAgeFilesLines
* qHash: make hashing of QLatin1StringView be the same as QStringThiago Macieira2024-03-121-0/+6
| | | | | | | Everywhere, except for ARM. Change-Id: I50e2158aeade4256ad1dfffd17b11ca2d57ad1fb Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* QHash: add the ability to detect whether qHash(t) == qHash(K(t))Thiago Macieira2024-03-121-0/+36
| | | | | | | | | | | | | | | | | | The typical examples are views and their corresponding owning container. Since they are different types, the search is heterogeneous, hence the name. We have to do it differently from the Standard Library. There, because the hasher is a template parameter to std::unordered_{map,set}, it can be a structure with overloads for different types, all of which the implementer guarantees produce the same hash for input that also compares equal. For QHash/QSet, we don't have a template parameter. One alternative solution would be to detect the existence of qHashEquals(T1, T2) or qHashHeterogeneousEquals() or something. Change-Id: I664b9f014ffc48cbb49bfffd17b0318c0775a2b5 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* qHash: backport the q(u)int128-to-quint64 reduction trick to 32-bitThiago Macieira2024-02-121-5/+18
| | | | | | | | | | I didn't do it in a template because the 32-bit code requires a compatibility hack for Qt 6 and it's using an XOR of the high and low parts. Fixes: QTBUG-116080 Change-Id: I5dd50a1a7ca5424d9e7afffd17ae0ba5b9ff52f6 Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
* Add missing qHash(qu/int128) overloadsMarc Mutz2024-02-121-1/+21
| | | | | | | | | | | | | | | | | | | | | | If we add the typedefs, we also need to add the qHash() overloads. See code comments for the explanation of how it works. I chose to use an addition to merge the upper and lower parts because of the comment in QHashCombineCommutative's operator(), introduced by commit 91b44afdcba3f4cb2ddc7a80c0cff723b408b447. Found in 6.6 API-review, but didn't make the cut and then was forgotten. Drive-by fix long line nearby. [ChangeLog][QtCore] Added qHash() overloads for quint128 and qint128. Fixes: QTBUG-116054 Task-number: QTBUG-116080 Change-Id: If484aed08ba476e0eace800b719f435203100f3e Reviewed-by: Ivan Solovev <ivan.solovev@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
* qHash: provide the long double overload on Darwin systemsThiago Macieira2024-02-031-2/+0
| | | | | | | | | | | | Commit c0791ac76ec7cfdc3945efa67a6f72ee3623413c didn't explain why it was #ifdef'ed out. It's just an alias for double. Maybe compilers at the time used to complain if you used it, but I can't make Apple's clang produce a warning now. Pick-to: 6.7 Change-Id: I664b9f014ffc48cbb49bfffd17b02293403e9571 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
* Bootstrap: remove QBitArrayMarc Mutz2024-01-311-0/+4
| | | | | | | | | | It appears to be used only in qlalr, which is, however, not bootstrapped. Pick-to: 6.7 6.6 6.5 6.2 Change-Id: Idc16d957bf687238c7b0ee603d8b092e2048ef18 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Remove redundant QPair includesAhmad Samir2023-09-061-1/+1
| | | | | | | | Nothing in those files uses QPair; and a local build finished fine without them. Task-number: QTBUG-115841 Change-Id: I669cfecaa9129bce6b31e464826287f138b159db Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QHash: tame HasQHashSingleArgOverload ODR violationsGiuseppe D'Angelo2022-11-011-9/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | qhashfunctions.h defines a catch-all 2-arguments qHash(T, seed) in order to support datatypes that implement a 1-argument overload of qHash (i.e. qHash(Type)). The catch-all calls the 1-argument overload and XORs the result with the seed. The catch-all is constrained on the existence of such a 1-argument overload. This is done in order to make the catch-all SFINAE-friendly; otherwise merely instantiating the catch-all would trigger a hard error. Such an error would make it impossible to build a type trait that detects if one can call qHash(T, size_t) for a given type T. The constraint itself is called HasQHashSingleArgOverload and lives in a private namespace. It has been observed that HasQHashSingleArgOverload misbehaves for some datatypes. For instance, HasQHashSingleArgOverload<int> is actually false, despite qHash(123) being perfectly callable. (The second argument of qHash(int, size_t) is defaulted, so the call *is* possible.) -- Why is HasQHashSingleArgOverload<int> false? This has to do with how HasQHashSingleArgOverload<T> is implemented: as a detection trait that checks if qHash(declval<T>()) is callable. The detection itself is not a problem. Consider this code: template <typename T> constexpr bool HasQHashSingleArgOverload = /* magic */; class MyClass {}; size_t qHash(MyClass); static_assert(HasQHashSingleArgOverload<MyClass>); // OK Here, the static_assert passes, even if qHash(MyClass) (and MyClass itself) were not defined at all when HasQHashSingleArgOverload was defined. This is nothing but 2-phase lookup at work ([temp.dep.res]): the detection inside HasQHashSingleArgOverload takes into account the qHash overloads available when HasQHashSingleArgOverload was declared, as well as any other overload declared before the "point of instantiation". This means that qHash(MyClass) will be visible and detected. Let's try something slightly different: template <typename T> constexpr bool HasQHashSingleArgOverload = /* magic */; size_t qHash(int); static_assert(HasQHashSingleArgOverload<int>); // ERROR This one *does not work*. How is it possible? The answer is that 2-phase name lookup combines the names found at definition time with the names _found at instantiation time using argument-dependent lookup only_. `int` is a fundamental type and does not participate in ADL. In the example, HasQHashSingleArgOverload has actually no qHash overloads to even consider, and therefore its detection fails. You can restore detection by moving the declaration of the qHash(int) overload *before* the definition of HasQHashSingleArgOverload, so it's captured at definition time: size_t qHash(int); template <typename T> constexpr bool HasQHashSingleArgOverload = /* magic */; static_assert(HasQHashSingleArgOverload<int>); // OK! This is why HasQHashSingleArgOverload<int> is currently returning `false`: because HasQHashSingleArgOverload is defined *before* all the qHash(fundamental_type) overloads in qhashfunctions.h. -- Now consider this variation of the above, where we keep the qHash(int) overload after the detector (so, it's not found), but also prepend an Evil class implicitly convertible from int: struct Evil { Evil(int); }; size_t qHash(Evil); template <typename T> constexpr bool HasQHashSingleArgOverload = /* magic */; size_t qHash(int); static_assert(HasQHashSingleArgOverload<int>); // OK Now the static_assert passes. HasQHashSingleArgOverload is still not considering qHash(int) (it's declared after), but it's considering qHash(Evil). Can you call *that* one with an int? Yes, after a conversion to Evil. This is extremely fragile and likely an ODR violation (if not ODR, then likely falls into [temp.dep.candidate/1]). -- Does this "really matter" for a type like `int`? The answer is no. If HasQHashSingleArgOverload<int> is true, then a call like qHash(42, 123uz); will have two overloads in its overloads set: 1) qHash(int, size_t) 2) qHash(T, size_t), i.e. the catch-all template. To be pedantic, qHash<int>(const int &, size_t), that is, the instantiation of the catch-all after template type deduction for T (= int) ([over.match.funcs.general/8]). Although it may look like this is ambiguous as both calls have perfect matches for the arguments, 1) is actually a better match than 2) because it is not a template specialization ([over.match.best/2.4]). In other words: qHash(int, size_t) is *always* called when the argument is `int`, no matter the value of HasQHashSingleArgOverload<int>. The catch-all template may be added or not to the overload set, but it's a worse match anyways. -- Now, let's consider this code: enum MyEnum { E1, E2, E3 }; qHash(E1, 42uz); This code compiles, although we do not define any qHash overload specifically for enumeration types (nor one is defined by MyEnum's author). Which qHash overload gets called? Again there are two possible overloads available: 1) qHash(int, size_t). E1 can be converted to `int` ([conv.prom/3]), and this overload selected. 2) qHash(T, size_t), which after instantiation, is qHash<MyEnum>(const MyEnum &, size_t). In this case, 2) is a better match than 1), because it does not require any conversion for the arguments. Is 2) a viable overload? Unfortunately the answer here is "it depends", because it's subject to what we've learned before: since the catch-all is constrained by the HasQHashSingleArgOverload trait, names introduced before the trait may exclude or include the overload. This code: #include <qhashfunctions.h> enum MyEnum { E1, E2, E3 }; qHash(E1, 42uz); static_assert(HasQHashSingleArgOverload<MyEnum>); // ERROR will fail the static_assert. This means that only qHash(int, size_t) is in the overload set. However, this code: struct Evil { Evil(int); }; size_t qHash(Evil); #include <qhashfunctions.h> enum MyEnum { E1, E2, E3 }; qHash(E1, 42uz); static_assert(HasQHashSingleArgOverload<MyEnum>); // OK will pass the static_assert. qHash(Evil) can be called with an object of type MyEnum after an user-defined conversion sequence ([over.best.ics.general], [over.ics.user]: a standard conversion sequence, made of a lvalue-to-rvalue conversion + a integral promotion, followed by a conversion by constructor [class.conv.ctor]). Therefore, HasQHashSingleArgOverload<MyEnum> is true here; the catch-all template is added to the overload set; and it's a best match for the qHash(E1, 42uz) call. -- Is this a problem? **Yes**, and a huge one: the catch-all template does not yield the same value as the qHash(int, size_t) overload. This means that calculating hash values (e.g. QHash, QSet) will have different results depending on include ordering! A translation unit TU1 may have #include <QSet> #include <Evil> QSet<MyEnum> calculateSet { /* ... */ } And another translation unit TU2 may have #include <Evil> #include <QSet> // different order void use() { QSet<MyEnum> set = calculateSet(); } And now the two TUs cannot exchange QHash/QSet objects as they would hash the contents differently. -- `Evil` actually exists in Qt. The bug report specifies QKeySequence, which has an implicit constructor from int, but one can concoct infinite other examples. -- Congratulations if you've read so far. ========================= === PROPOSED SOLUTION === ========================= 1) Move the HasQHashSingleArgOverload detection after declaring the overloads for all the fundamental types (which we already do anyways). This means that HasQHashSingleArgOverload<fundamental_type> will now be true. It also means that the catch-all becomes available for all fundamental types, but as discussed before, for all of them we have better matches anyways. 2) For unscoped enumeration types, this means however an ABI break: the catch-all template becomes always the best match. Code compiled before this change would call qHash(int, size_t), and code compiled after this change would call the catch-all qHash<Enum>(Enum, size_t); as discussed before, the two don't yield the same results, so mixing old code and new code will break. In order to restore the old behavior, add a qHash overload for enumeration types that forwards the implementation to the integer overloads (using qToUnderlying¹). (Here I'm considering the "old", correct behavior the one that one gets by simply including QHash/QSet, declaring an enumeration and calling qHash on it. In other words, without having Evil around before including QHash.) This avoids an ABI break for most enumeration types, for which one does not explicitly define a qHash overload. It however *introduces* an ABI break for enumeration types for which there is a single-argument qHash(E) overload. This is because - before this change, the catch-all template was called, and that in turn called qHash(E) and XOR'ed the result with the seed; - after this change, the newly introduced qHash overload for enumerations gets called. It's very likely that it would not give the same result as before. I don't have a solution for this, so we'll have to accept the ABI break. Note that if one defines a two-arguments overload for an enum type, then nothing changes there (the overload is still the best match). 3) Make plans to kill the catch-all template, for Qt 7.0 at the latest. We've asked users to provide a two-args qHash overload for a very long time, it's time to stop working around that. 4) Make plans to switch from overloading qHash to specializing std::hash (or equivalent). Specializations don't overload, and we'd get rid of all these troubles with implicit conversions. -- ¹ To nitpick, qToUnderlying may select a *different* overload than the one selected by an implicit conversion. That's because an unscoped enumeration without a fixed underlying type is allowed to have an underlying type U, and implicitly convert to V, with U and V being two different types (!). U is "an integral type that can represent all the enumerator values" ([dcl.enum/7]). V is selected in a specific list in a specific order ([conv.prom]/3). This means that in theory a compiler can take enum E { E1, E2 }, give it `unsigned long long` as underlying type, and still allow for a conversion to `int`. As far as I know, no compiler we use does something as crazy as that, but if it's a concern, it needs to be fixed. [ChangeLog][Deprecation Notice] Support for overloads of qHash with only one argument is going to be removed in Qt 7. Users are encouraged to upgrade to the two-arguments overload. Please refer to the QHash documentation for more information. [ChangeLog][Potentially Binary-Incompatible Changes] If an enumeration type for which a single-argument qHash overload has been declared is being used as a key type in QHash, QMultiHash or QSet, then objects of these types are no longer binary compatible with code compiled against an earlier version of Qt. It is very unlikely that such qHash overloads exist, because enumeration types work out of the box as keys Qt unordered associative containers; users do not need to define qHash overloads for their custom enumerations. Note that there is no binary incompatibity if a *two* arguments qHash overload has been declared instead. Fixes: QTBUG-108032 Fixes: QTBUG-107033 Pick-to: 6.2 6.4 Change-Id: I2ebffb2820c553e5fdc3a341019433793a58e3ab Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Replace usages of Q_CLANG_QDOC with Q_QDOCLuca Di Sera2022-10-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | 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>
* QtBase: eradicate QT_STRINGVIEW_LEVEL usesMarc Mutz2022-07-201-2/+0
| | | | | | | | | | | | It's not used and not useful. The macro itself has to stay, for now, because Qt5Compat uses it, too. Task-number: QTBUG-100861 Pick-to: 6.4 6.3 6.2 Change-Id: I5d0557a6c959d6facf6e47f26786a9d365339e95 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* Long live QT6_{DECL,IMPL,CALL}_NEW_OVERLOAD!Marc Mutz2022-07-201-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We have in the past found ourselves in need of disambiguating new overloads from older, QT_REMOVED_SINCE'ed ones, which we usually did by adding a defaulted int argument, cf. e.g. QMetaType::id(). The problem with a defaulted int argument is twofold: First, an int is a valid argument type, and users may get confused as to its meaning when presented with the signature in the IDEs auto-completion popup, and a lot of things implicitly convert to an int, so any errornous parameter passing may stay unnoticed until we remove these fake arguments come Qt 7. Second, this way of doing things requires a lot of ifdef'ery to keep the additional argument out of both the docs and future Qt 7 builds. The solution presented in this patch is to create a tag type, QDisambiguated_t, which a) more clearly communicates its purpose and b) doesn't implicitly convert from anything. To help with the invariably ugly ifdef'ery, provide a set of macros that hide this stuff from qdoc and Qt 7 builds. Use the macros to replace the fake int arguments that were added for 6.4. Pick-to: 6.4 Change-Id: I6916f38c8eb9793ad6dea5f61e7e5fff7e75e273 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* qHash: pass QByteArrayView to qHash() by valueThiago Macieira2022-06-151-0/+8
| | | | | | | | | | | | | The QBAV one should pass the parameter by value, like QStringView. And now that we have it, the non-View one should call the View one in an inline function, like we already do for QString. The extra, defaulted parameter is there only so we get a different signature in the new inline function compared to the removed one. Pick-to: 6.4 Change-Id: If05aeeb7176e4f13af9afffd16e7f08062b1dc86 Reviewed-by: Marc Mutz <marc.mutz@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>
* qhashfunctions.h: add std::hash specialization for QByteArrayViewThiago Macieira2022-04-221-0/+1
| | | | | | | | [ChangeLog][QtCore][QByteArrayView] Added std::hash specialization. Change-Id: If05aeeb7176e4f13af9afffd16e7f03dfa413a66 Reviewed-by: Rui Oliveira Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
* QtCore: Replace remaining uses of QLatin1String with QLatin1StringViewSona Kurazyan2022-03-261-2/+2
| | | | | | | Task-number: QTBUG-98434 Change-Id: Ib7c5fc0aaca6ef33b93c7486e99502c555bf20bc Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* Use qstringfwd.h when forward declaring string classesSona Kurazyan2022-03-121-3/+1
| | | | | | Task-number: QTBUG-98434 Change-Id: I37b70a1b7bc164fa7dc9cb702827297ca66a6fdc Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QHashSeed: remove 'pure' attribute on globalSeed()Marc Mutz2022-02-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While 'pure' in GCC is weaker than Stepanov's Regular Procedure from Elements of Programming (equal result for equal inputs), it does not allow accesses to volatile memory: > functions declared with the pure attribute can safely read any > non-volatile objects The globalSeed() function reads from an atomic variable that can be changed at any time from another thread. Atomics, while not volatile objects in the sense of the keyword, must fall under the pure attribute doc's exclusion criterion: The difference between a volatile and an atomic access, while important for the implementation of the function, is indistinguishable to the caller of the function: both volatile and atomic objects can change value without the current thread of execution changing them, with no way for the caller of the function to distinguish which one occurred. Therefore, globalSeed() should not be pure. 5.15 is not affected, as qGlobalQHashSeed() is not marked as pure. Task-number: QTBUG-62185 Pick-to: 6.3 6.2 Change-Id: I6fc52e2bd41ef4aa3f8039072b47c7a1314b98fa Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QT_SPECIALIZE_STD_HASH_TO_CALL_QHASH: use unqualified qHash() lookupMarc Mutz2021-11-291-4/+7
| | | | | | | | | | | ... instead of QT_PREPEND_NAMESPACE(qHash), which is qualified (prepends at least '::'), and therefore disables ADL. This is not a problem as long as we wrote our qHash() overloads as free functions (incl. non-hidden friends), but it should™ fail for hidden friends, so use the old using-std::swap() trick to bring QT_PREPEND_NAMESPACE(qHash) into scope, proceeding with an unqualified lookup. Pick-to: 6.2 Change-Id: I00860b2313699849f86bfe3dd9f41db4ce993cd3 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* QHash: fix qHash(std::pair)Thiago Macieira2021-05-231-2/+15
| | | | | | | | | | | | | | There were two problems here: first, qHash(std::pair) must be declared before qHashMulti that might call back to qHash(std::pair) (i.e., a pair with one element that is also a pair). But moving the declaration above causes the second problem: the noexcept expression can't refer to qHash functions that aren't declared yet. So we forward-declare a constexpr function for that result, but implement it far below. Fixes: QTBUG-92910 Change-Id: Ia8e48103a54446509e3bfffd16767ed2e29b026c Reviewed-by: Christian Kandeler <christian.kandeler@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Deprecate qGlobalQHashSeed and qSetGlobalQHashSeed in Qt 6.6Thiago Macieira2021-05-231-1/+4
| | | | | | | That's two years from when the replacements were added (6.2). Change-Id: Id2983978ad544ff79911fffd1671f7dd38fede02 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Mark QHashSeed::globalSeed() noexceptThiago Macieira2021-05-231-1/+1
| | | | | | | | | | | | | | | It is noexcept, except when initializing. When initializing, let's just use qEnvironmentVariableIntValue (which we should have used anyway), which avoids the memory allocation and is noexcept. The QRandomGenerator functions are not marked noexcept, but are mostly so: they can't throw regular exceptions, but some implementations do call POSIX Thread Cancellation Points, which may cause forced stack unwinding. That's unlikely to happen at the moment of the QHash initialization. This is also mitigated in the next commit. Change-Id: Id2983978ad544ff79911fffd1671fd16f8d6378d Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Introduce QHashSeed and switch to size_t seedsThiago Macieira2021-05-231-0/+12
| | | | | | | | | | | Commit 37e0953613ef9a3db137bc8d3076441d9ae317d9 added a to-do, but we can actually change the type, since we've documented since Qt 5.10 that setting a non-zero value (aside from -1) with qSetGlobalQHashSeed was not allowed. Storing a value to be reset later is simply not supported. Change-Id: Id2983978ad544ff79911fffd1671f7b5de284bab Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
* QFlags: add qHash overloadGiuseppe D'Angelo2021-05-111-0/+4
| | | | | | | | | Stop going through the implicit int conversion. [ChangeLog][QtCore][QFlags] QFlags now has a qHash() overload. Change-Id: Id380ed252695f24af2e8c239b650dcb6f44e2893 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QHash: add a Qt 7 TODOGiuseppe D'Angelo2021-03-211-0/+1
| | | | | | | | | | The hashing seed's type has been changed from int to size_t in Qt 6. However the functions setting/getting the seed, and the seed itself, are still simply int, meaning that we've crippled our seeding. Add a TODO to amend it. Change-Id: Ie9dd177149ec299ccf16d4e31f9f4b065804cfed Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Add a qHashEquals() method and use it to compare keys in QHashLars Knoll2020-12-041-0/+6
| | | | | | | | | | | | | | | In some cases, the default equality operator for a class is not suitable for using in hashing (for example because it uses fuzzy comparisons). Add a qHashEquals() method that by default uses the equality operator, but allows to tailor the operations that should be used when using the class as a key in QHash. Task-number: QTBUG-88966 Change-Id: I346cf0e6e923277a8b42a79e50342a1c2511fd80 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> (cherry picked from commit 5d8b586e73e37070b0303bee24372550854637eb) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Seedless qHash catch-all: make it SFINAE-friendlyGiuseppe D'Angelo2020-11-301-2/+10
| | | | | | | | | | | | | | | | | To support qHash overloads without a seed we have a qHash(T, size_t) catch-all that calls qHash(T) and XORs the seed. The problem is that this catch-all is not SFINAE friendly. For a type Foo which does not have any qHash overload, we can't ask if qHash(Foo, size_t) is callable because it would instantiate the catch-all and fail to compile. Add a suitable trait and enable_if. Pick-to: 6.0 Change-Id: Idffd48a537eebaf77cee7030b8d91a302643ffde Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
* Whitespace cleanup in corelib/toolsAllan Sandfeld Jensen2020-10-211-2/+4
| | | | | Change-Id: Ibe796c398a8e5488b7203abb07aa54740744f1ab Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Long live QKeyCombination!Giuseppe D'Angelo2020-09-031-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | C++20 via P1120 is deprecating arithmetic operations between unrelated enumeration types, and GCC 10 is already complaining. Hence, these operations might become illegal in C++23 or C++26 at the latest. A case of this that affects Qt is in key combinations: a QKeySequence can be constructed by summing / ORing modifiers and a key, for instance: Qt::CTRL + Qt::Key_A Qt::SHIFT | Qt::CTRL | Qt::Key_G (recommended, see below) The problem is that the modifiers and the key belong to different enumerations (and there's 2 enumerations for the modifier, and one for the key). To solve this: add a dedicated class to represent a combination of keys, and operators between those enumerations to build instances of this class. I would've simply defined operator|, but again docs and pre-existing code use operator+ as well, so added both to at least tackle simple cases (modifier + key). Multiple modifiers create a problem: operator+ between them yields int, not the corresponding flags type (because operator+ is not overloaded for this use case): Qt::CTRL + Qt::SHIFT + Qt::Key_A \__________________/ / int / \______________/ int Not only this loses track of the datatypes involved, but it would also then "add" the key (with NO warnings, now its int + enum, so it's not mixing enums!) and yielding int again. I don't want to special-case this; the point of the class is that int is the wrong datatype. Everything works just fine when using operator| instead: Qt::CTRL | Qt::SHIFT | Qt::Key_A \__________________/ / Qt::Modifiers / \______________/ QKeyCombination So I'm defining operator+ so that the simple cases still work, but also deprecating it. Port some code around Qt to the new class. In certain cases, it's a huge win for clarity. In some others, I've just added the necessary casts to make it still compile without warnings, without attempting refactorings. [ChangeLog][QtCore][QKeyCombination] New class to represent a combination of a key and zero or more modifiers, to be used when defining shortcuts or similar. [ChangeLog][Potentially Source-Incompatible Changes] A keyboard modifier (such as Qt::CTRL, Qt::AltModifier, etc.) should be combined with a key (such as Qt::Key_A, Qt::Key_F1, etc.) by using operator|, not operator+. The result is now an object of type QKeyCombination, that stores the key and the modifiers. Change-Id: I657a3a328232f059023fff69c5031ee31cc91dd6 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Move QStringRef and remains to Qt5CompatKarsten Heimrich2020-08-201-4/+0
| | | | | | | | | 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>
* Replace Qt CONSTEXPR defines with constexprAllan Sandfeld Jensen2020-08-141-14/+14
| | | | | | | | Both normal and relaxed constexpr are required by our new minimum of C++17. Change-Id: Ic028b88a2e7a6cb7d5925f3133b9d54859a81744 Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
* Introduce QByteArrayViewSona Kurazyan2020-07-081-0/+1
| | | | | | | | | | | | | | | | | | | | 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>
* Port remaining usages of QStringRef in QtCore to QStringViewLars Knoll2020-06-121-3/+5
| | | | | | Task-number: QTBUG-84319 Change-Id: If77bc94c18e8d522b4577050091cd7d7aa941311 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Long live std::pair!Giuseppe D'Angelo2020-06-101-9/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make QPair an alias for std::pair, and qMakePair just a forwarder towards std::make_pair. Why? Fundamentally to ditch a bunch of NIH code; gain for free structured bindings, std::tuple and std::reference_wrapper compatibility, and so on. Breakages: * Some that code manually forward declares QPair. We don't care about it (<QContainerFwd> is the proper way). * Some code that overloads on std::pair and QPair. Luckily it's mostly centralized: debug, metatypes, testing macros. Just remove the QPair overload. * Usages of qMakePair forcing the template type parameters. There are a handful of these in qtbase, but only one was actually broken. * std::pair is NOT (and will never likely be) trivially copiable. This is agreed to be a mistake done by practically all implementations in C++11, can can't be fixed without breaking ABI. Some code using QPair assuming it's trivially copiable may break; exactly one occurrence was in qtbase. * QMetaType logic extracts the type names in two different ways, one by looking at the source code string (e.g. extracted by moc) and one via some ad-hoc reflection in C++. We need to make "QPair" (as spelled in the source code) be the same as "std::pair" (gathered via reflection, which will see through the alias) when compared. The way it's already done e.g. for QList is by actually replacing the moc-extracted name with the name of the actual type used in C++; do the same here. On libc++, std::pair is actually in an inline namespace -- i.e. std::__1::pair; the reflection will extract and store "std::__1::pair" so we need an ad-hoc fix to QMetaType. [ChangeLog][QtCore][QPair] QPair is now an alias to std::pair, and does not exist as a class in Qt any more. This may break code such as functions overloaded for both QPair and std::pair. Usually, the overload taking a QPair can be safely discarded, leaving only the one taking a std::pair. QPair API has not changed, and qMakePair is still available for compatibility (although new code is encouraged to use std::pair and std::make_pair directly instead). Change-Id: I7725c751bf23946cde577b1406e86a336c0a3dcf Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Long live qHashMulti(Commutative)Giuseppe D'Angelo2020-05-121-4/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | Add a helper function so that we have a shortcut. Instead of writing: QHashCombine hash; seed = hash(seed, fieldA); seed = hash(seed, fieldB); // etc. return seed; one can now simply write: return qHashMulti(seed, fieldA, fieldB, fieldC); Port a few usages inside qtbase as a demonstration. [ChangeLog][QtCore][QHash] Added the qHashMulti and qHashMultiCommutative functions as convenience helpers to calculate a hash from multiple variables (typically, data members of a class). Change-Id: I881a9ad41168df20ceecc6588a94abe7ddc6a532 Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
* Provide qHash for all C++ fundamental typesGiuseppe D'Angelo2020-05-081-9/+21
| | | | | | | | | | Except for (void and) bool, which we may not want to have to avoid accidental implicit conversions. Drive-by, rearrange qHash overloads to C++ types first, and then Qt ones. Change-Id: I9c4ecef5f28568d35ca52e339583851ce53b3bae Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* QHashFunctions: port to if constexprGiuseppe D'Angelo2020-05-051-1/+1
| | | | | | | | Condition is a compile-time one. Change-Id: I6e60f12cc51e96b2528c375017357c0631e2fc0b Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
* Optimize hashing of floating point numbersLars Knoll2020-04-091-1/+8
| | | | | | Change-Id: Id5e091b135c006b10987f229f45319228edb8675 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Fix compiler warning on 32bitLars Knoll2020-04-091-6/+7
| | | | | | Change-Id: I8728ba339161e210772e73c633cb2309dfb01b8e Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Change qHash() to work with size_t instead of uintLars Knoll2020-04-091-39/+40
| | | | | | | | | | | 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>
* Implement better hash functions for integer typesLars Knoll2020-02-151-14/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | The hash function provides rather good mixing of the input bits. It spreads numbers out evenly through the uint range, a change of one bit in the input changes around half the output bits, and it is pretty fast. Using this as a hash function over the simple hash(int) == int has the advantage that it reduces the amount of collisions for badly distributed keys. In addition, it allows us to always use power of two sizes for the hash table, leading to better performance for inserts and lookups. the 32 and 64 bit hash functions where chosen from https://nullprogram.com/blog/2018/07/31/. I selected the ones that give a very good distribution of the hash values while using the integer for both multiplication steps. This should be slighty faster than using two different numbers. While the result is still being cast to a uint, the method is prepared so it can handle 64 bit keys and seeds. Fixes: QTBUG-29009 Change-Id: Id7a1b97b3c0d219e65de2e6e1fe6faf092f8ce16 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* qhashfunctions.h: add specializations of std::hash for some Qt typesMarc Mutz2019-05-291-0/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We have a problem. Our types don't play well with the std unordered containers, because they do not specialize std::hash. We therefore force our users to come up with an implementation, hindering interoperability, since any two developers are unlikely to come up with compatible implementations. So combining libraries written by different developers will result in ODR violations. Now that we depend on C++11, and thus the presence of std::hash, we still face the problem that the standard does not provide us with a means to compose new hash functions out of old ones. In particular, we cannot, yet, depend on C++17's std::hash<std::string_view> to implement std::hash<QByteArray>, say. There's also no std::hash for std::tuple, which would allow easy composition by using std::tie(). So piggy-back on the work we have done over the years on qHash() functions, and implement the std::hash specializations for Qt types using the existing qHash() functions, with a twist: The standard allows implementations to provide means against predictable hash values. Qt has this, too, but the seed is managed by the container and passed to the qHash() function as a separate argument. The standard does not have this explicit seed, so any protection must be implicit in the normal use of std::hash. To reap whatever protection that std library has on offer, if any, we calculate a seed value by hashing int(0). This will be subject to constant folding if there's no actual seed, but will produce a value dependent on the seed if there is one. Add some tests. A question that remains is how to document the specialization. Can we have a \stdhashable QDoc macro that does everything for us? Task-number: QTBUG-33428 Change-Id: Idfe775f1661f8489587353c4b148d76611ac76f3 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Merge "Merge remote-tracking branch 'origin/5.13' into dev" into ↵Qt Forward Merge Bot2019-04-041-26/+26
|\ | | | | | | refs/staging/dev
| * Replace Q_DECL_NOEXCEPT with noexcept in corelibAllan Sandfeld Jensen2019-04-031-26/+26
| | | | | | | | | | | | | | In preparation of Qt6 move away from pre-C++11 macros. Change-Id: I44126693c20c18eca5620caab4f7e746218e0ce3 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | Remove remaining Q_DECL_NOEXCEPT/Q_DECL_NOTHROW usageAllan Sandfeld Jensen2019-04-041-7/+7
|/ | | | | Change-Id: I91ac9e714a465cab226b211812aa46e8fe5ff2ab Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* JSON: Add qHash functions for JSON and CBOR typesUlf Hermann2018-08-271-0/+5
| | | | | | | This way we can easily use them as keys in QHash and QSet. Change-Id: Ie744c3b5ad1176ba2ab035c7e650af483757a0c9 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* doc: Fix three "Cannot tie" errorsMartin Smith2017-12-021-1/+1
| | | | | | | | | | Two of the three functions were for functions that should not be documented. The third was a function protected by #ifndef Q_OS_DARWIN, which required a test of Q_CLANG_QDOC in the header and cpp files. Change-Id: Id2ab3e4f2ea896dc628a622de2e80a19c18eb9fe Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
* Allow to chain qt_hash() callsMarc Mutz2017-03-301-1/+1
| | | | | | | | | There are some callers of qt_hash that first build a string just to hash it. By allowing to pass an initial value for 'h', we can chain qt_hash() calls to avoid having to allocate memory just to hash a two-part string. Change-Id: Ifaca82d47b2fb8c707912342c3ddd84f91e70267 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Add qHash(QStringView)Marc Mutz2017-03-301-1/+4
| | | | | | | | [ChangeLog][QtCore] Added qHash(QStringView). Change-Id: I69c9203cf301fe586e924168381884aab2e19e5c Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com> Reviewed-by: Anton Kudryavtsev <antkudr@mail.ru>
* Replace internal qt_hash(QString(Ref)) functions with one taking QStringViewMarc Mutz2017-03-301-2/+1
| | | | | | Change-Id: I49d07689e642d26b4bceda5cace738aadd828ce0 Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com> Reviewed-by: Anton Kudryavtsev <antkudr@mail.ru>
* Merge remote-tracking branch 'origin/5.6' into 5.7Liang Qi2016-05-191-0/+3
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: configure src/3rdparty/angle/src/libANGLE/renderer/d3d/d3d11/Renderer11.cpp src/network/access/qnetworkaccessmanager.cpp src/plugins/platforms/cocoa/qcocoacolordialoghelper.mm src/plugins/platforms/eglfs/deviceintegration/eglfs_kms/qeglfskmsgbmcursor.cpp src/plugins/platforms/eglfs/deviceintegration/eglfs_kms/qeglfskmsgbmcursor.h src/widgets/widgets/qlineedit_p.cpp src/widgets/widgets/qlineedit_p.h src/winmain/winmain.pro tests/auto/corelib/io/qstorageinfo/tst_qstorageinfo.cpp tests/auto/dbus/qdbusconnection/tst_qdbusconnection.cpp tests/auto/dbus/qdbusconnection/tst_qdbusconnection.h tests/auto/testlib/selftests/expected_cmptest.teamcity tests/auto/testlib/selftests/expected_cmptest.txt tests/auto/widgets/itemviews/qtableview/tst_qtableview.cpp tools/configure/configureapp.cpp Change-Id: Ib9997b0d0f91946e4081d36c0c6b696c5c983b2a
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-09 00:58:38 +0000