From: Rob Stewart (stewart_at_[hidden])
Date: 2004-04-08 11:20:10
From: Vladimir Prus <ghost_at_[hidden]>
> 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_at_[hidden] Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk