[Development] Behaviour change in QML in Qt 5.8 regarding null

Simon Hausmann 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:

        QVariant::fromValue<void *>(nullptr);

which does

    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...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160927/7fe6e93b/attachment.html>

More information about the Development mailing list