[Development] QDateTime is missing shared null optimization

[Thiago Macieira]

On Saturday 01 August 2015 23:22:45 Robert Knight wrote:
> > What I mean is that you'll incur a heap allocation when doing
> > ...
> > I don't think there is and there has never been any inline method in
> > QDateTime that dereferences the d pointer, so using a nullptr to indicate
> > shared null is acceptable.
> 
> Hmm, perhaps QDT could avoid a heap allocation entirely in common
> cases on 64-bit systems? eg. When using a standard timezone (no custom
> offset) and the date/time can be represented as a positive offset from
> the UNIX epoch less than some max value.  Something like 42 bits for
> ms since 1970, 5 bits for the timezone, 1 tag bit to indicate not a
> d-ptr.  Its quite possible I missed some obvious flaw, but just a
> thought.

That's a very good idea.

We'd need to check how complex the conversions would be, though. 

QDateTime API accepts the offset from UTC in seconds, but all existing 
timezones are multiples of a quarter hour. With a range from -12 to +13.5,  we 
need ceil(log((13.5 + 12) * 4) / log(2)) = 7 bits for the timezone. With the 
one bit for the tag, we have 48 bits left for the msecs portion on 64-bit 
platforms.

A 48-bit millisecond field spans 3257812 days. JD 3257812 is 4207-06-27.

Anyone want to try this?

Please note you cannot manipulate the this pointer in a member function, so 
all the QDateTimePrivate member functions need to be made static first.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center