From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-02-14 11:29:00
> Any plans on adding support for parsing wchar_t in the program_options lib?
> It is hard coded with std::string right now which makes it kind of useless
> in a program where argv is a wchar_t**.
The review manager indicated that unicode (~= whar_t) support is needed for
the final version of library, so yes, there are such plans. The problem is
that it's probably the only planned change for which I haven't yet decided
> It could be templatized so that it can be based on any kind of
Alas, that would break ability to put all sources in a library -- thereby
increasing compile time for users who don't need wchar_t support.
> Alternatively, you could use preprocessor defines to control whether it
> builds for ANSI or UNICODE. This would probably be adequate for its
> intended use as well as less complicated to implement but I suspect it
> would not be portable enough for BOOST.
That's an option too. Could you answer a couple a questions to help me with
1. Do you need wchar_t for option values, or for option names too?
2. Do you plan to mix char and wchar_t? If so, how 'char' is to be converted
to wchar_t? What if I require to provide a converting function for that case?
3. If you plan to use wchar_t for option names, how will use specify names in
code? Using unicode literals or using some specific 8-bit encoding? If the
latter, how convertion to unicode is to be done? Again, is user-provided
converter okay for you?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk