[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