[Development] QDateTime is missing shared null optimization
thiago.macieira at intel.com
Mon Aug 3 03:39:56 CEST 2015
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
More information about the Development