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