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
