Hi Martin,
This issue has come up with quite regular intervals. The current docs says a little bit about this: "Where a higher degree of control is required over conversions, std::stringstream and std::wstringstream offer a more appropriate path."
My concern is that the current implementation gives you a false sense of portability. The documentation says nothing nothing about locales. Even the test cases for lexical_cast assumes the default "C" locale. E.g. BOOST_CHECK_EQUAL("1.23", lexical_cast<std::string>(1.23));
I think there should be a big warning about using lexcial_cast for convering numbers to/from text. The only safe place I see is when the resulting string is used to create user messages.
A quick scan shows that at least "program options" uses lexical_cast for other things than user messages. lexical_cast is used to validate entries and to create default values. This means that the options must be specified in the locale the application uses (which might not be the same as the computer is running). This might be intentional but it is not documented so I have no idea how program options works in my locale.
I think that it's not such a big problem. If you want to use locales, then your application should start with: std::locale::global(std::locale("")); after that, I think lexical_cast will use the default user's locale. Or you can replace "" above with something else that your application wants. The only problem is that it's not possible to use several locales in one application. For program_options, it's not very important. Why do you need to specify locales for call to 'lexical_cast'? - Volodya