[Development] Proposal: adding Q_DECL_NOEXCEPT to many methods

Konrad Rosenbaum konrad at silmor.de
Fri Aug 3 09:58:24 CEST 2012


On Thursday 02 August 2012 23:01:55 you wrote:
> On Thursday August 2 2012, Konrad Rosenbaum wrote:
> > On Thursday 02 August 2012, Thiago Macieira wrote:
> > > On quinta-feira, 2 de agosto de 2012 17.55.54, Konrad Rosenbaum wrote:
> > > > Where is qHash(QDateTime) defined? It doesn't seem to be where I
> > > > expected it (qhash.* or qdatetime.*).
> > > 
> > > qdatetime.{h,cpp}
> > 
> > Ok, found it - had the wrong branch checked out for some odd reason. This
> > has a high likelyhood of causing allocations if time zones, calenders or
> > anything fancy is active: it causes time zone calculations, which
> > potentially cause allocations.
> 
> That begs the question whether this is what should happen for a _hash_,
> which is supposed to be _fast_ :)

All three (QDate, QTime, QDateTime) take the somewhat obvious route of 
converting to a linear measure of time (julian day, msecs since midnight, 
msecs since epoch) that is then fed to qHash(qint64 time,int seed).

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.

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?

Alternative 1: the hash for QDateTime could be calculated from other internal 
details: the hashes of the QDate and QTime objects making up the QDateTime 
plus TimeSpec, UTC-offset, and later on a reference to the time zone. If we do 
this it means the generated hashes will change in Qt 5.1!

Alternative 2: the hash for QDateTime is calculated solely from the hashes of 
QDate and QTime. Upside: they do not change, they are easy and fast to 
calculate, we already know the sources are noexcept. Trade: we trade 
equivalence of the exact same time relative to Epoch across time zones 
(currently the hash of "2012-08-03 9:54:00 +200" equals the hash of 
"2012-08-03 7:54:00 UTC") for equivalence of the exact same numeric time over 
time zones (hash of "2012-08-03 9:54:00 +200" equals the hash of "2012-08-03 
9:54:00 UTC") - I view both as equivalent for the most common case of using 
local time only.



	Konrad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120803/8ce441a8/attachment.sig>


More information about the Development mailing list