[Development] QDateTime is missing shared null optimization

[Thiago Macieira]

On Monday 03 August 2015 03:23:44 Mark Langezaal wrote:
> On 2015-08-01 23:51, Thiago Macieira wrote:
> > 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.
> 
> Actually you used 1 + 7 + 48 = 56 bits, which leave another 8 bits for

Ooops... Einstein also failed at basic math, you know? :-)

> useful data such as Spec. Or am I missing something obvious here?
> What is the recommended way to share a d-ptr with other data? By using a
> union on the d-ptr and a struct containing bit fields?

We don't need more than 7 bits for the timespec. With 56 bits, we get a span 
of 833999930 days. If we used it signed, we get a range up until the year 
1136995, which is plenty.

To support up until year 9999, we need 49 bits. If we make it signed, that's 
50 bits. We have 6 bits free then.

In order to do this, yes, you'd put the structure with the bit fields in the 
same union as the d pointer. Please be careful about endianness. The tag bit 
must be the first bit in little-endian and the last bit in big-endian.

And like I'd said below: you cannot call any of the QDateTimePrivate member 
functions when d isn't a real pointer.

> > 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