On 2015-02-18 12:14, Thiago Macieira wrote: > On Wednesday 18 February 2015 17:44:05 Olivier Goffart wrote: >> On Wednesday 18 February 2015 11:25:54 Matthew Woehlke wrote: >>> 1. How does this interact with QSettings? If I directly pass an enum to >>> e.g. QSettings::setValue, is it written as an int or an enum (I guess >>> int)? What about if I use QVariant::fromValue (i.e. so the variant type >>> is the enum)? >> >> I have not tried QSettings yet, but since it works with QVariant it should >> work. > > But if already worked, this means the new file format will be different than > what it used to. We may actually have to keep the current format so old > applications can read the settings file produced by new applications.
(Did you mean to say that backwards? I would generally expect new settings may not be compatible with old code...) I'm not sure there is an issue here. If I do this: settings.setValue(key, enumValue); ...I think this relies on implicit conversion to int (because QVariant can't construct from an arbitrary type without fromValue, correct?), and so will (continue to) write a number. Even with Q_ENUM. Therefore, this won't break. Similarly, a QVariant with a "genuine enum type" was not previously convertible (correct?), so anyone that is *using* fromValue to serialize is also overloading the stream operators anyway, and in such case probably will not switch to Q_ENUM (or at least will be aware of the possible consequences of doing so). IOW I don't think any existing code will change by accident just by starting to use Q_ENUM. (There might be a case for allowing conversion of QVariant with an int to an enum, if the int is a valid enum value. For that matter, does the other direction work? If I have a QVariant with an enum, can I get the numeric value from that without knowing the enum type?) -- Matthew _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
