$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: Martin (adrianm_at_[hidden])
Date: 2004-09-21 06:14:44
> 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. 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.
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.
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.