Boost logo

Boost :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-09-21 07:15:11


Martin wrote:

>> So every library which uses lexical_cast would have to provide the
>> 'imbue' and store the locale everywhere? I think per-thread global
>> variable is better.
>
> I think you missed my point.

Yes, and you've partly missed my ;-)

> All operations that involves string handling
> (sorting, parsing etc) need to do that within a certain context which is
> called locale. However, all string handling desen't necessary work with
> the same locale. That is why the STL streams, string_algo etc all allow
> you to specify the locale to use per instance or function.
>
> If you introduce another global (or per-thread global) variable it will
> not solve anything since lexical_cast might be used in different libraries
> where I want to use different locales.

The point of mine that you've missed is that if you're using one library at
a time, then you can use per-tss locale so that while you're using one
library, the locale is right.

The points of yours that I've missed is that you might really want to use
two libraries at a time. For example, program_options might have on-demand
LDAP source with different locales, so when user tries to get an option,
parsing should be done with the right locale, while the user has no idea
which one.

> A (thread-) global variable calld program_options_locale could work but it
> would be just as easy to make it a class-member.
>
> You don't allow differnt locales in your library and neither does
> lecxical_cast so they work nice together. But if you want to support
> different locales in your library you can't use lexical_cast and that is
> my whole point with this discussion.

Agreed.

> Lexical_cast is supposed to make a common task easy and reduce the risk of
> errors but instead it gives you a false sense of security and motivates
> others to also ignore locale support.

:-(
Ultimately, I might drop the use of lexical_cast.

- Volodya


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