On Saturday 15 April 2017 00:49:35 Giuseppe D'Angelo wrote: > * Q_DECLARE_TYPEINFO over suitable Standard Library datatypes;
I can only think of std::pair here, and it's done already, in qhashfunctions.h Specifically, we can say nothing about any of the std containers, as they are free to choose their own implementation. E.g. a std::string with SSO is not trvially relocatable. std::pair is special, since the standard prescibes a layout for it. > * defining qHash over suitable Standard Library datatypes; This is the hard one. One could come up with wrappers for each std header, and add qHash() there, but realisically, I don't think it's worth it. If you have std keys, use std types. This dependency inversion is yet another reason to stop providing std facilities in Qt (as soon as we realistically can). > * defining std::hash specializations for suitable Qt datatypes; This is simple, from a header pov: you only need to #include <functional>. The problem here is that, absent std::basic_string_view, you have no way to hash arbitrary memory (without first constructing a std::string, that is). The underlying issue is that any user-specialisation of std::hash should delegate to a stdlib-provided one, because implementations are free to add seeding, and, lacking an extra argument, the only way to incorporate the seed is to call a library-provided specialisation. So while it's trivial to add std::hash specialisations for something like QVector, QSizePolicy or QPoint (but not QPointF, because its op== is broken), I currently don't see how we could add them for QString or QByteArray, at least without looping over std::hash<char>, which imo is a no-no. Thanks, Marc -- Marc Mutz <[email protected]> | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
