From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-04-08 01:03:41
> After reading all the discussion about the complexity of the unicode and
> considering your arguments, I withdraw the idea of fully templated
> 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...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk