[Development] Behaviour change in QML in Qt 5.8 regarding null
Simon.Hausmann at qt.io
Tue Sep 27 20:22:34 CEST 2016
I'm fairly sure we used QVariant(QMetaType::VoidStar);
From: thiago.macieira at intel.com
Sent: September 27, 2016 19:26
To: development at qt-project.org
Subject: Re: [Development] Behaviour change in QML in Qt 5.8 regarding null
On terça-feira, 27 de setembro de 2016 09:31:14 PDT Thiago Macieira wrote:
> On terça-feira, 27 de setembro de 2016 15:29:16 PDT Simon Hausmann wrote:
> > That said, I think it can be written without #ifdef perhaps by using
> > QVariant::isNull() ?
> > (QVariant(nullptr) maps to isNull() as well, right? ;-)
> It should.
Actually, I'm not sure it should.
QVariant's only pointer constructor is the one for const char*, which will be
null if the pointer is null too. That would support the proposition that
QVariant(nullptr).isNull() because QVariant((const char*)nullptr).isNull().
However, to create a VoidStar, you need to write:
return QVariant(qMetaTypeId<T>(), &t, QTypeInfo<T>::isPointer);
That constructor always sets d.is_null = false. So the QVariant is not null,
as it contains a valid VoidStar value. It just happens that the VoidStar
itself is null. In other words, QVariant behaves like a non-null void**
pointing to a null void*.
What's more, it's very likely that your QML-created VoidStar also would report
isNull() == false, so you can't write that for current code either to detect a
null JSON value.
Unless you created it with:
is that the case?
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Development mailing list
Development at qt-project.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Development