[boost] Re: Re: Re: Re: [program_options] Unicode support

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-04-08 01:06:27

Rob Stewart wrote:

>> So insted of writing unicode::whatever as in your proposal, "whatever"
>> will be thin templated layer, that will convert application specific data
>> to the format understood by the core library and vice versa. This layer
>> should be fully dependant on locales to do the required conversion. These
>> can be suplied by imbue().
> 
> Wouldn't it be better to use an installable translator (a policy
> class or a strategy class?) that leaves up to the client the
> responsibility to perform the required string operations like
> concatenation (perhaps not needed), searching for a substring,
> trimming a string, etc.  That is, have the program_options
> library defer all string operations, that require customization
> to support Unicode strings, to the client.
> 
> Then, the library can provide the default, std::string
> implementation, and clients can, as they see fit for their own
> Unicode types, provide alternatives.  Eventually, there may be a
> few accepted translators that can be added to the library, but
> for now, program_options won't need to define them, yet it will
> be ready for the future.

Hi Rob,

I think this solution has a drawback. The approach we were discussing allows
the user to obtain wstring from wchar_t command line now, without writing
any code at all. What he does with that wstring is up to him but he gets
the string.

I'm afraid that if user can't get this out-of-box, it's hard to say that
'program_options supports unicode'.

- Volodya