[Development] QDateTime is missing shared null optimization
Thiago Macieira
thiago.macieira at intel.com
Fri Jul 31 18:08:13 CEST 2015
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
More information about the Development
mailing list