[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