$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
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