From: Vladimir Prus <ghost@cs.msu.su>
Rob Stewart wrote:
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.
I think this solution has a drawback. The approach we were discussing allows the user to obtain wstring from wchar_t command line now, without writing any code at all. What he does with that wstring is up to him but he gets the string.
I'm afraid that if user can't get this out-of-box, it's hard to say that 'program_options supports unicode'.
I didn't think there was an expectation that things would work with Unicode, given the various Unicode formats and markers (or whatever Miro called them). Perhaps you're saying that a strict pass-through, without any conversions to other types, will work. I still don't know how you'll parse command lines with Unicode unless you know how to find each character. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;