From: Pavol Droba <droba@topmail.sk>
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.
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. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;