[internal API] new LocaleDataWrapper::stringToDouble()
erack at redhat.com
Fri Oct 27 21:20:08 UTC 2017
adds two new LocaleDataWrapper::stringToDouble() functions (one taking
a const OUString& and the other const sal_Unicode* for start and end).
For a detailed description see include/unotools/localedatawrapper.hxx
These should be used whenever a string with locale dependent decimal and
group separators is to be parsed as a floating-point number into
a double, instead of obtaining separators from a LocaleDataWrapper
instance and calling rtl::math::stringToDouble().
Background is that due to
now an alternative input decimal separator can be defined and these
functions take care of that.
I already changed existing places that called
rtl::math::stringToDouble() locale dependent, for example
SvNumberFormatter::IsNumberFormat() is also adapted, so places using
that need no change, same for cclass_Unicode::parseText() and thus
XCharacterClassification::parsePredefinedToken() and parseAnyToken() and
their class CharClass wrappers.
Also adapted are implementations in BASIC that use ImpGetIntntlSep().
Code that implements (why?) some own parsing likely has to be adjusted to
accept the alternative as well
Another thing I encountered was
connectivity/source/commontools/predicateinput.cxx that uses separators
obtained by getSeparatorChars(). I wasn't sure if and what change it
would need and the implications a change there would have.
Anyway, the OSQLParseNode::parseNodeToPredicateStr() used to translate
it back taking a casted (yuck) sal_Char separator looks crap and doesn't
work correctly with Arabic locales (and maybe others).
LibreOffice Calc developer. Number formatter stricken i18n transpositionizer.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A
Care about Free Software, support the FSFE https://fsfe.org/support/?erack
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: not available
More information about the LibreOffice