Re: [boost] Re: Re: Re: Re: [program_options] Unicode support

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;