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

Marc Mutz marc.mutz at kdab.com
Sat Apr 15 08:15:44 CEST 2017


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 <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts



More information about the Development mailing list