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

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

Hi Pavol,

> After reading all the discussion about the complexity of the unicode and
> considering your arguments, I withdraw the idea of fully templated
> implementation.
> 
> However, maybe something in between might be feasible. Actualy your
> interface is quite close. What I would like to propose, is to have a core
> part working with an arbitrary encoding (implementation defined) and a set
> of templated interfaces.

What I planned was core part (or parsers) working with specific encoding and
overloads of interface function for char and wchar_t. In fact, close to
what you propose.

> 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().

We now have 'typed_value' class which is responsible for converting string
into needed type. It's template already, so another template -- char type
to use, will be fine.

> This would simplify interface from the user perspective. User will not
> have the use (IMHO unnatural) unicode prefix, interface will be flexible
> and open for any reasonable encoding, yet the core library will have all
> the properties you have declared as imporatant. (compiled separately,
> working with a single encoding and etc.)

I should only comment about 'unicode' prefix. I meant it as an way to easily
switch from ascii to unicode. E.g. you have

   ("foo", value<int>(), "foo")

which uses ascii. You add 'using namespace boost::program_options::unicode'
above and it uses unicode. But, OTOH, given that I (for now) expect that
most options will be parsed using ascii, maybe this convenience
optimization is premature. Nothing is wrong with:

   ("foo", value<int, wchar_t>(), "foo")

> Does this seem reasonable to you?

Yes, it appears the basic approach is settled. Need to iron out some details
and start coding again...

Thanks,
VOlodya