[Development] How to include Standard Library headers from Qt ones?

[Giuseppe D'Angelo]

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 | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - Qt, C++ and OpenGL Experts

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4007 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170415/0de2b176/attachment.bin>