Boost logo

Boost :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-02-14 11:29:00

Hi Bryan,
> 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
the design.

> It could be templatized so that it can be based on any kind of
> std::basic_string.

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, gregod at, cpdaniel at, john at