summaryrefslogtreecommitdiffstats
path: root/src/corelib/tools/qhashfunctions.h
Commit message (Collapse)AuthorAgeFilesLines
* 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
| * Move q{Set,}GlobalQHashSeed() to the correct header fileMarc Mutz2016-05-131-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The <QHash> only contains the container these days, while <QHashFunctions> contains the qHash() function overloads and related functions. This is where these two functions belong, too. This change is BC and SC, since qhash.h includes qhashfunctions.h. Change-Id: I2e7febb0ffca209af67fb9f2cd363596867a44e1 Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | Updated license headersJani Heikkinen2016-01-151-14/+20
| | | | | | | | | | | | | | | | | | | | | | From Qt 5.7 -> LGPL v2.1 isn't an option anymore, see http://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation/ Updated license headers to use new LGPL header instead of LGPL21 one (in those files which will be under LGPL v3) Change-Id: I046ec3e47b1876cd7b4b0353a576b352e3a946d9 Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
* | Add qHash(std::pair)Marc Mutz2015-12-301-0/+9
|/ | | | | | | | | | | We already include <utility> in <qglobal.h>, so we might as well provide a qHash() overload for std::pair. [ChangeLog][QtCore] Added qHash(std::pair), defined in <QHashFunctions>. Change-Id: I0f61c513e82e05ce9d2e56bcf18f3be9e2da4da9 Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
* Split qHash()-related code into separate headerMarc Mutz2015-04-081-0/+156
The reduces the amount of code the compiler has to parse when all the header does is implement its own qHash(). I left the implementation in qhash.cpp, as it doesn't influence qHash*() users. Change-Id: Id320d690a33769bae78b03ccc3b08f7124123459 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com> Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-23 22:52:49 +0000