[boost] [lexical_cast] Locale used during conversion

Subject: [boost] [lexical_cast] Locale used during conversion
From: Adam Badura (abadura_at_[hidden])
Date: 2009-05-29 05:19:42

    lexical_cast does not allow to pass the locale to be used during 
conversion. This is justified with analogy of lexical_cast to other casts 
which all take only one parameter. So lexical_cast always uses the current 
global locale. A reasonable choice.

    However I wanted to propose some additional features.

    It would be useful to provide (lets call it so for now) 
classic_lexical_cast which would use std::locale::classic() instead of the 
global one.
    I just finalized globalization/localization of our application by adding 
setting of the global locale to appropriate value according to the selected 
language. I noticed that all of sudden serialized data (mainly projects) 
stopped loading/saving correctly. The reason was easy to find. Where 
previously we had XML node named "item1000" we now have "item1,000" in 
English or "item1 000" in Polish for example. The projects are no longer 
interchangeable between applications running in different language version.
    I corrected this by adding our own lexical_cast which resets the global 
locale to the classic one, calls boost::lexical_cast and finally resets the 
global locale back. This special cast is used now whenever we are dealing 
with texts which are not presented to the final user.
    This works fine however it seems that resetting the global locale often 
(each time we save a number in the project for example...) is causing 
significant performance overhead. (Exact tests have not been yet performed 
but this seems the only change which might have affected all serialization 
slowdown.) I might reset it before saving the project and then save the 
project as usually but this is not very handy as I would have to remember to 
do it each time I am serializing any data.
    Also other problems are implied. Other threads for the short period of 
time see different global locale as well and thus might produce bad strings.
    And in the end it is impractical. It would be handy to have 
classic_lexical_cast as well as it could introduce some optimizations 
knowing that the requested locale is the classic one.

    Another thing is that it would be handy to introduce a function 
textual_convert (another example name) which would act like lexical_cast but 
would take the requested locale as a parameter (this is no longer a cast so 
it may).
    lexical_cast might take that locale as a second parameter with default 
value being the global locale so it could still be used just as any other 
casting. But I suppose this would not be well seen. Thus why not introduce a 
different function for that (or maybe there already is one?).

    It seems those changes would not be difficult to implement and could be 
hidden in the details of lexical_cast easily.
    What do you think of that?

    Finally lexical_cast's documentation might mention explicitly that 
current global locale is used as it does not mention that if I am not 
mistaken (I haven't found "locale" word in that document).

    Adam Badura