> 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. On 31 July 2015 at 18:08, Thiago Macieira <[email protected]> wrote: > On Friday 31 July 2015 17:20:02 Milian Wolff wrote: >> Most other classes in Qt are cheap to generate in an empty/invalid state, >> not so for QDateTime. Is there a reason for that, or is it just an >> oversight? > > Oversight. > >> If so, I'd like to amend that. Would it be preferred to >> introduce a shared null like QTypedArrayData::sharedNull, or should I >> rather use a nullptr to indicate the invalid state, like in QImage? Or am I >> missing something and these tricks are not applicable to QDateTime? > > 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. > > I also don't think you can have a full, static shared null because > QDateTimePrivate is not POD, due to its QTimeZone member. So a real shared > null would be a Q_GLOBAL_STATIC, if you chose to go that route. > > Another piece of information is that I removed all sharing in Qt 5.5 because > it was badly implemented before. QDateTime does a lot of lazy evaluation, > which is incompatible with implicit sharing. You have to choose one or the > other. > >> Grepping for QSharedDataPointer, I find many more classes that do not >> leverage a shared null state. Should we try to implement some helper >> functions/macros there which can be leveraged by every user of this class >> to implement a shared null state? > > Some of them may not do it because of the lazy evaluations I mentioned. > > Another is that QSDP/QESDP don't do a clone-from-null very well. I think there > are a couple of specialisations of QSDP<T>::clone that implement this > functionality, which you can grep for. Check with Marc' and see if his new, > internal shared pointer class could take this optimisation. > > -- > 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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
