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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
