On sexta-feira, 3 de agosto de 2012 09.58.24, Konrad Rosenbaum wrote: > For QTime and QDate this is uncritical - these are the native storage > format, although a few methods would have to be marked noexcept as well.
Which I've done, except for inline methods.
> For QDateTime this potentially involves heavy calculations. The upside of
> this is that this guarantees unchanged hashes even if the internal
> representation of QDateTime changes. How hard is the requirement to create
> the same hash over several versions of Qt?
Zero.
The only requirement on a hash is
a == b → qHash(a) == qHash(b)
The value returned by the qHash function can be *anything*, provided it meets
the above requirement. So it's possible to change the internal hashing
function.
The problem with QDateTime is that the operator== also does some calculations.
It compares as equal two QDateTime objects with different times and timezones,
provided that they are the same universal time.
And operator== can't change incompatibly.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 556189-6027
Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
