Il 15/04/2017 08:15, Marc Mutz ha scritto: > 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.
There may be others: std::complex comes to mind; or maybe std::array; or maybe other stuff that's going to be added later. We got a Get Out of Jail Free card with std::pair because <utility> was already included from qglobal.h, what do we do for the others? > >> * 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). This is kind of a harsh resolution. Are people fine with it? The danger is of course downstreams defining their own qHash(std::...) all over the place. And we can't universally recommend unordered associative containers from std (or even deprecate QHash!) because of the next point... > >> * defining std::hash specializations for suitable Qt datatypes; > > This is simple, from a header pov: you only need to #include <functional>. I definitely think std::hash specializations should be added for all suitable types; and mandating a specialization of std::hash should also be part of the coding policies. Yet, how many datatypes in Qt offer std::hash right now? > 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. Not to mention that * combining the results of looping over std::hash<char> may well not yeild the same results of applying std::hash<string_view> over the whole sequence; * there isn't a hash combiner in the std (so we'd still be needing ours); * it's not guaranteed that the hashing algorithm used by std::hash on a type's internal representation is also the best algorithm for the values that that type can actually represent (but rolling your own algorithm, and not using std::hash, makes you lose the seeding or any other goodies done by the implementation). There's a huge discussion in N3980. Cheers, -- Giuseppe D'Angelo | [email protected] | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - Qt, C++ and OpenGL Experts
smime.p7s
Description: Firma crittografica S/MIME
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
