On Wednesday, 18 de January de 2012 00.47.31, John Layt wrote: > * QString will need a decision on the behaviour of toInt() / toLong() / etc > using the Default Locale.
They should use the C locale, not the Default (System) locale. Anything in
QtCore, outside of QLocale, should default to the C locale unless otherwise
explicitly requested. To deal with a specific locale, including the system one,
the user needs to use QLocale or use explicit locale-relevant routines.
Higher-level classes, in end user-facing situations, like widgets and QML,
however, should default to the system locale.
We need to avoid the problem of printf / scanf that use different decimal
conventions depending on the user locale. That means the naive implementation
will be unable to parse the data it generated under a different locale
settings.
This is a slightly behaviour-incompatible change, but one I feel is justified:
reading / parsing of data with comma as a decimal separator was already
broken, so we don't break it further; generating of data without thousands
separators and with dots instead of commas for decimals is a minor
inconvenience.
> QLocale has friends which use QLocalePrivate methods and enums to perform
> number parse/format.
>
> * QString
> * QByteArray
> * QIntValidator
> * QDoubleValidatorPrivate
> * QTextStream
> * QTextStreamPrivate
>
> Other classes call public QLocale methods for number symbols like
> decimalPoint() and negativeSign() to use in their own custom char-at-a-time
> parse/format routines which will cause an issue as ICU / CLDR define these
> symbols as strings and not chars.
QTextStream defaults to the C locale but it has a setLocale member for
changing that. QString and QByteArray can only do the C locale, except where
the system one is explicitly requested ("%L1").
The validators (which are in QtGui) need a setLocale too, but unlike
QTextStream they should default to the system locale.
Does anyone see a problem with different defaults?
> QString - Well behaved, only uses the QLocalePrivate number methods and
> enums. Mostly only uses C Locale, but does use Default Locale first in
> toInt() / toLong() / etc methods, and in arg() methods if %L override used.
See above.
> QByteArray - Very well behaved, only uses the QLocalePrivate number methods
> and enums, only uses C Locale.
Good, looks done.
> QIntValidator & QDoubleValidator - Very well behaved, only uses the
> QLocalePrivate number methods and enums. You can set/get locale to use,
> defaults to Default Locale but falls back to C Locale.
Falling back is a bad idea, unless a Nokian can dig up from the old history of
that codebase a compelling reason why it was done like that.
> QDateTimeParser is a private class used for basic date/time parsing in
> QLocale and QDateTime, but as a validating parser in QDateTimeEdit where it
> is very deeply embedded. It only uses the Default Locale unless you
> sub-class it. QLocale and QDateTime can easily port to use ICU (QDateTime
> probably using C Locale) but QDateTimeEdit still needs QDateTimeParser.
> It's not a great class or widget, so I'd suggest doing the minimal work
> required to port to ICU, rename it QDateTimeEditParser and move it to
> Widgets.
Agreed.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 556189-6027
Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
