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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
