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