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> |
||
---|---|---|
.. | ||
.gitignore | ||
qhashfunctions.pro | ||
tst_qhashfunctions.cpp |