|
Boost : |
From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-09-21 00:47:43
Martin Adrian wrote:
>>Why do you need to specify locales for call to 'lexical_cast'?
....
> But, it is also common to do things in an application that doesn't follow
> the system globale like parsing and writing xml or csv files, generating
> SQL statements etc. (program options might fall into theis category as
> well)
I think in many cases only encoding (utf8,koi8-r, etc) of external sources
matters, for example email headers do not specify locale, only encoding.
But anyway, encoding is part of locale, too.
> When it comes to program options the author
To clarify, "the author" is I.
> has decided to use
> lexical_cast and the global locale to verify input. It might be a good
> choice but it means that you can't move configuration files between
> computers with different locales.
It's already the case, because config file do not contain the information
about the used locale. Further, even if it did, the set of locales on
different computers is not the same, and on different OS even the naming
may be different, so moving configuration files is hard already.
This might mean I need to set classic locale for parsing, to make sure
config files are really portable.
So far, I'm not sure how lexical_cast (or other function) can support
locales. The way you suggest -- additional parameter, if fine, but then
you need to pass the locale parameter via several levels of function calls:
for program_options it's po::store, value_semantic::parse, po::validator
and then finally lexical_cast. That's not convenient, so probably global
"lexical_cast_locale" is better. But for MT environment you need to store
that global state in TSS.
- Volodya
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk