Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk