[Development] QVairant::Type enums are now obsolete?
Harald Fernengel
harald.fernengel at nokia.com
Tue Aug 21 10:21:12 CEST 2012
Hi,
On Monday 20 August 2012 17:42:51 ext Thiago Macieira wrote:
> On segunda-feira, 20 de agosto de 2012 11.22.12, Stephen Chu wrote:
> > I just noticed that all the QVariant::Type enums are now marked as
> > obsolete in 5.0 doc:
> > http://qt-project.org/doc/qt-5.0/qvariant-obsolete.html#Type-enum
> >
> > The goal seems to be to switch to QMetaType enums. But in the attempt to
> > make my code up-to-date, I find that strait replace of the old names
> > with the new can be very problematic. For example the following 2 lines
> >
> > of code produce different variants:
> > QVariant v1(QMetaType::QString);
> > QVariant v2(QVariant::String);
> >
> > v1 is a int with value 10 and v2 is a QString with empty content.
> >
> > It seems a QVariant constructor that takes a QMetaType::Type is needed.
>
> No, we don't think so.
>
> We ruled that the constructor with a Type and nothing else was a design
> flaw. It creates a null QVariant with a valid type, including types for
> which null isn't possible, like int:
>
> bool isNull(int i)
> {
> // what goes here?
> }
>
> So it's not a complete replacement. When you're replacing your code, you
> should also fix the above code to be actually meaningful.
Note that the concept of "NULL" values, while generally a bad idea, is a
concept required for the SQL module. SQL has the conecpt of "NULL" as an extra
flag for every value (date, int, string, etc. etc.).
That's why we added the is_null bitfield as extra flag on every QVariant, and
allowed people to construct QVariants that had a valid type but not a non-
valid (NULL) value.
Harald
More information about the Development
mailing list