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