4469e36d72
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> |
||
---|---|---|
.. | ||
auto | ||
baselineserver | ||
benchmarks | ||
global | ||
libfuzzer | ||
manual | ||
shared | ||
testserver | ||
README | ||
tests.pro |
This directory contains autotests and benchmarks based on Qt Test. In order to run the autotests reliably, you need to configure a desktop to match the test environment that these tests are written for. Linux X11: * The user must be logged in to an active desktop; you can't run the autotests without a valid DISPLAY that allows X11 connections. * The tests are run against a KDE3 or KDE4 desktop. * Window manager uses "click to focus", and not "focus follows mouse". Many tests move the mouse cursor around and expect this to not affect focus and activation. * Disable "click to activate", i.e., when a window is opened, the window manager should automatically activate it (give it input focus) and not wait for the user to click the window.